Welcome to Caché!  

Moving a database is really straightforward:

  1. Find the database definition in your 2007.1 instance in the System Management Portal
  2. Note the physical Directory where the cache.dat is located
  3. Shut down Caché and make a copy of the cache.dat file located in that Directory
  4. On 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 instance

Hope that helps!


See this thread which discusses several options for server-side Studio hooks for Git:

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:


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.



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!


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:

NOTE - 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.  


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:


Based on your URL above, give this a try:


Report back and let us know if this works, and don't forget to "Accept" the answer if it does :)

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 Century

As 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 environments
  • Private BASEs for some apps
  • BASE, TEST and LIVE branches
  • VCS is Perforce
  • Serverside hooks on Shared BASE control concurrency and locking of items as they are being edited on Shared BASE
  • All 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 branch
  • Changed items are pulled from TEST branch into TEST environment and compiled
  • Same process for moving things from TEST to LIVE

This 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).

There is a huge benefit from two perspectives:

- If you need to refresh data in your Dev or Test environment, you can just grab the globals DB from Live and drop it in and not worry about overwriting any code in Dev or Test

- If you choose to deploy your code via a DB drop, you can drop in a new DB to replace the existing routines DB

NOTE - for either of these to work, you may need to map configuration into the routines DB (so you don't bring back Live config into Dev for instance)



FYI ... we will have several sessions covering this topic at the Global Summit - attend if you can, otherwise check out the material afterwards!

For internal application development within InterSystems we use a variety of approaches, but the most common is as follows:

1) We use an internally developed issue tracking system, but we plan to eventually migrate to JIRA

2) We use Perforce for all of our source control 

3) We have BASE, TEST and LIVE environments for every application, typically BASE and TEST being cloned from VM snapshots of LIVE.  In addition to the Shared BASE VM, for those applications which are undergoing the highest rate of change, developers will create a local copy of the application to do their development work.  Some apps have all changes being developed on Shared BASE and the changes are progressed (via our Change Control tool) to TEST and the LIVE.  For applications where developers use Private BASEs, they commit there and then push the changes to Shared BASE and then to TEST and LIVE.

Feel free to ask questions (here or at Global Summit)!

Thanks for asking.


I know that customers have set this up before.  Here are some old notes that I found which may point you in the right direction.  NOTE - I have never done this myself so I con't be of much help beyond pointing out this starting point:

Implementation Outline:
1. Configure CSP to accept IIS's authentication headers and pass them to Caché

2. Set up delegated authentication to use existing security model to assign $username and $roles 
based on the user's domain accountname and/or domain groups. (Implement ZAUTHENTICATE.MAC)

3. Enable delegated authentication for any desired services and CSP applications -- in this case 
the system management portal.
·  Configuration (e.g. CSP application definition)
·  Login Page Logic decides based on Gateway Service User, whether to trust REMOTE_USER HTTP 
header, or to prompt for username/password (other fields such as PIN are also an option).




Here is some sample code that should help get you going in the right direction.  NOTE - the byRef LD argument is a handle for the connection to the LDAP server and it needs to be cleaned up when you're done if you're going to fetch any attributes.  

(sorry for the messed up indentation)

 /// Authenticates against the configured domain, with username/password, passing a resulting a status ByRef and a returning success/failure value
ClassMethod Authenticate(username As %String, password As %String, ByRef Status As %Status, ByRef LD As %Integer) As %Boolean
Set Status=$$$OK, ret=0
If ('$data(username))||('$data(password)) 
    Set Status=$$$ERROR($$$GeneralError,"Both fields are required") 
    Quit 0

Set sc=$$$OK
Try {
//Connect to the LDAP server
Set LDAPServer=""
Set sc=$$$OK
Set LD=##class(%SYS.LDAP).Init(LDAPServer)
If LD=0 {
        Set LDAPStatus=##class(%SYS.LDAP).GetLastError()
        Set sc=$$$ERROR($$$GeneralError,"LDAP Init Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
Else {
    //Authenticate the passed in user by using the Binds command 
    Set Domain=..GetDomain()
    If ($$$isWINDOWS) {
        Set LDAPStatus=##Class(%SYS.LDAP).StartTLSs(LD)
        If LDAPStatus'=$$$LDAPSUCCESS {
        Set sc=$$$ERROR($$$GeneralError,"LDAP StartTLSs Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
    Else {
        Set LDAPStatus=##Class(%SYS.LDAP).Binds(LD,"",$lb(username,Domain,password),$$$LDAPAUTHNEGOTIATE)
        If LDAPStatus'=$$$LDAPSUCCESS {
        Set sc=$$$ERROR($$$GeneralError,"LDAP Binds Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
ElseIf ($$$isUNIX) {
    Set cert = ..GetCert()
    Set LDAPStatus=##Class(%SYS.LDAP).SetOption(LD,$$$LDAPOPTXTLSCACERTFILE,cert)
    If LDAPStatus'=$$$LDAPSUCCESS {
        Set sc=$$$ERROR($$$GeneralError,"LDAP SetOption Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
        Do ..RotateOnFailure(sc)
Else {
        Set LDAPStatus=##Class(%SYS.LDAP).StartTLSs(LD)
        If LDAPStatus'=$$$LDAPSUCCESS {
        Set sc=$$$ERROR($$$GeneralError,"LDAP StartTLSs Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
    Set LDAPStatus=##Class(%SYS.LDAP).SimpleBinds(LD,username_"@"_Domain,password)
    If LDAPStatus'=$$$LDAPSUCCESS {
        Set sc=$$$ERROR($$$GeneralError,"LDAP SimpleBinds Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
Else {
If (LDAPStatus'=$$$LDAPSUCCESS)&&($$$ISOK(sc)) {
    Set sc=$$$ERROR($$$GeneralError,"LDAP API Error: "_##class(%SYS.LDAP).Err2String(LDAPStatus))
Catch err {
    Set sc = $$$ERROR($$$GeneralError,err.Data) 
If $$$ISOK(sc) {
     Set ret = 1
Else {
    Set Status = sc 

Quit ret