go to post Ben Spead · Oct 17, 2018 Daniel,You are absolutely correct that using Client-Side source control hooks (ie the Eclipse Git hooks with Atelier) in a Shared development instance is a recipe for disaster and frustration. You options are moving to Private development environments (each developer gets their own Namespace, or instance, or VM or container), or move to Server-side source control hooks.I did an in depth session on this at Global Summit 2017 which should be of interest to you. You can watch the recording and get the slides here:https://learning.intersystems.com/course/view.php?id=713HTH,Ben
go to post Ben Spead · Sep 7, 2018 Please contact InterSystems Support for assistance on this:https://www.intersystems.com/support-learning/support/immediate-help/Thank you,Ben
go to post Ben Spead · Aug 15, 2018 Eduard - I think Arcady was asking from a purely data-processing perspective. I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing? I think it's a good question and I would also like to hear what people think :)
go to post Ben Spead · Jun 19, 2018 I should have searched just a little longer.obj.%Reload() I found this in Documatic for my class (inherited because it is persistent)
go to post Ben Spead · May 9, 2018 If you call LOG^%ETN it will dump all of the stack into the Application Error Log which you can access via the management portal or the terminal.http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ATRYCATCHFAQ has some discussion on LOG^%ETN which may be helpful.Ben
go to post Ben Spead · Apr 25, 2018 In the Management Portal go to: System > Configuration > Memory and StartupChange the System Mode and it will put a custom banner in the header indicating Dev / Test / Live
go to post Ben Spead · Apr 24, 2018 Kumar,It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct? If so, you are bound to experience frustration with this due to consistency issues.Please review https://learning.intersystems.com/course/view.php?id=713 which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.
go to post Ben Spead · Apr 20, 2018 Kumar,If you are using CCR then there are very specific requirements in terms of development workflow which will provide assurances of no source loss, etc. Please open a ticket with Support to discuss these specific concerns and considerations.In summary, there can only be a single Disconnected BASE environments for each System, because the CCR Client Tools manage source concurrency within the Namespace, and if you have multiple BASE namespaces you have lost concurrency and therefore can lose source. Atelier will work the same as Studio - you need a single Shared Dev Namespace using the CCR Client Tools (aka server-side source hooks) and at that point you can use either Atelier or Studio to edit the source in BASE.IMPORTANT NOTE: Server-side hooks will only work properly with Atelier if you are running a database version that includes CDS2924. This is included in 2016.2.3+, 2017.1.2+ and 2017.2.0+ only. If you are not sure if you have CDS2924 or not, please contact Support (if you use Atelier against a Shared Dev instance that doesn't have CDS2924 you don't have concurrency and therefore can lose source).Hope that helps to get you started in the right direction :)
go to post Ben Spead · Jan 25, 2018 Geoffroy,Welcome to Caché! Moving a database is really straightforward:Find the database definition in your 2007.1 instance in the System Management PortalNote the physical Directory where the cache.dat is locatedShut down Caché and make a copy of the cache.dat file located in that DirectoryOn your 2017.1 instance create a new database definition in the System Management Portal an point the Directory to the location of the copy of the cache.dat that you copied from your 2007.1 instanceHope that helps!Ben
go to post Ben Spead · Jan 19, 2018 See this thread which discusses several options for server-side Studio hooks for Git:https://community.intersystems.com/post/are-there-server-side-git-studio...NOTE - in my use-case I was looking for server-side hooks in order to allow concurrent server-based development, and I discovered that Git is very poorly suited for that purpose. I ended up abandoning Git and using Perforce instead for my demo (Perforce is very well suited for server-side hooks with concurrent server-based development). If you are you already operating in a single-developer / single instance setup and if you can move to one of the very latest versions of the product (2017.2.0+ or 2017.1.2+) then you should take a look at Atelier with client-side source control hooks.For a thorough review of the different development models (private instance vs shared instance) and the different source control hook approaches (client-side vs server-side), I highly recommend that you watch the following session from last year' Global Summit:https://learning.intersystems.com/course/view.php?id=713
go to post Ben Spead · Jan 4, 2018 Stephen,An advantage to this is that the WRC will have a history of snapshots of your config and some basic operating data so that if you need to contact them about a performance issue, behavior change, etc, they could look back and see changes which have taken place in your system that might impact current behavior. Several large customers take advantage of this to make it easier to see trends in their instances.HTH,Ben
go to post Ben Spead · Nov 24, 2017 Check out the full tutorial which includes REST API set-up:https://community.intersystems.com/post/lets-write-angular-1x-app-cach%C...
go to post Ben Spead · Nov 15, 2017 I completely agree - this would make the results much more helpful!
go to post Ben Spead · Nov 3, 2017 You can do this via the following (it is a little hidden):Studio > File > Change Namespace > Connect > (select instance) > Enter credentials and uncheck "Remember Password"Could you please give this a try and let us know if it works for you?
go to post Ben Spead · Oct 11, 2017 I have received a stream before as follows in my WebService client: Method MyWebMethod(pAction As %String = "", ByRef pFile As %FileCharacterStream = "", ByRef pDataSet As %XML.DataSet = "") As %xsd.base64Binary [ Final, ProcedureBlock = 1, SoapBindingStyle = document, SoapBodyUse = literal, WebMethod ]{...}I am able to use this method signature to both receive files from the web service as well as send files to the web service.Hope that helps!Ben
go to post Ben Spead · Oct 10, 2017 Studio Source Control (aka Server-side Source Control hooks) are supported if you are using against DBs with version 2016.2 or greater. If you are one one of these versions and are having issues, I suggest you contact the WRC.For more details on using Server-side hooks with Atelier, check out this presentation from the Global Summit:https://learning.intersystems.com/course/view.php?id=713NOTE - you need to make sure that your DB version has CDS2924 in it in order to protect against a serious bug which would allow Atelier to overwrite things which a user has not checked out of source control. This will be included in 2017.2.0, 2017.1.2 and 2016.2.3, or you can request it in an Adhoc from the WRC if required.
go to post Ben Spead · Sep 27, 2017 Armin, I took a quick look and the good news is that the Ensemble Management Portal is just wrapping a DS Dashboard. This means that you can stick this in an iFrame in SharePoint (I think this is called the "Page Viewer Webpart") and point the source to the DeepSee Dashboard Viewer page with the Embed flag turned on. E.g. the following link works for me: http://localhost:57772/csp/ensdemo/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard Based on your URL above, give this a try: http://ntvensemble03/csp/activity/_DeepSee.UserPortal.DashboardViewer.zen?EMBED=1&NOBORDER=1&DASHBOARD=Ens%2FDeepSee%2FActivityVolumeAndDuration.dashboard Report back and let us know if this works, and don't forget to "Accept" the answer if it does :)
go to post Ben Spead · Sep 18, 2017 Ian - I completely understand why moving to Private Dev is challenging. It is very much the nature of applications built on top of InterSystems technology, and it is certainly a challenge. You are absolutely correct in your thinking that you will see a lot of issues in trying to use Client-Side source hooks (especially for a distributed source control system like Git) against a Shared Dev instance. I actually presented at Global Summit last week about the interplay between Client vs Serverside hooks and Private vs Shared Dev instances, and I recommended that people avoid the Client-Side / Shared Dev combination. I would recommend that you download the slides and watch the recording of my session - you will probably find it to be very helpful:Global Summit 2017: Shared Development for the 21st CenturyAs you are tied to Shared Dev workflow, I would strongly suggest that you consider using Server-side hooks to enable your dev workflow, and that you use a centralized Version Control System (VCS) like Perforce, Deltanji or Subversion rather than a distributed VCS like Git. Serverside hooks will enforce the behavior of both Studio and Atelier, so you can still move to Atelier and still use this (just make sure that you are on 2017.2.0, 2017.1.2 or 2016.2.3 as those are the first versions that contain a fix to a hole that was recently found in serverside protections with Atelier). In terms of your code promotion question, please keep in mind that Atelier is a development tool and not a deployment tool. As others have said, TEST and PROD should never have code pushed to it from Atelier but rather the code needs to come directly from your VCS. I run internal app dev at InterSystems and our process looks like this:Shared BASE, TEST and LIVE environmentsPrivate BASEs for some appsBASE, TEST and LIVE branchesVCS is PerforceServerside hooks on Shared BASE control concurrency and locking of items as they are being edited on Shared BASEAll check-ins include a logic identifier for the project (a Job in Perforce) When project is ready to move from BASE to TEST, we have a script that integrates all changelists with that Job from the BASE branch to the TEST branchChanged items are pulled from TEST branch into TEST environment and compiledSame process for moving things from TEST to LIVEThis process works very well for us and scales well on a variety of sized development teams (larger teams use more private BASE environments to prevent check-out collisions on Shared-BASE). We've been working in this mode for about 7 years and it's really stabilized our environments and branches (compared to how things were before) and we're well positioned to move forward with Atelier in use side by side with Studio.Hope this helps. Please watch my Global Summit session and let me know if you have any questions (I plan to write a new article based on my session so feel free to jump in to the discussion there).
go to post Ben Spead · Sep 15, 2017 Ian - the appropriateness of your architecture relies very much on whether or not there will be more than one developer working on this application and having access to these environments. Can you please clarify that point?
go to post Ben Spead · Sep 5, 2017 The following article (and it's ensuing discussion) may also be of interest to everyone:https://community.intersystems.com/post/studio-tip-running-cos-commands-...HTH,Ben