New post
AllAccepted answers
Jeffrey Drumm · Jul 14, 2017

It appears as though an expression won't work in the target field. Interestingly, though, this actually compiles for me on 2017.1:

It errors when the rule executes:

I've done dynamic routing in a BPL code bock using ObjectScript, though, and you could certainly write your own BP in Studio for it ... see the methods SendRequestSync()/SendRequestAsync() in Ens.Host, of which Ens.BusinessService/BusinessOperation/BusinessProcess are subclasses.

Jeffrey Drumm · Jul 3, 2017

Yes, and InterSystems provides quite a few examples for developing Business Services. A Service generally extends an existing class, since there's a lot of operational stuff that is common between services. A Service also has a Parameter that defines the Adapter class it uses, which provides the methods to communicate with other processes/applications/servers. You can browse the EnsLib package for something that comes close to fitting your needs, then create a new class that either extends it or replaces its functionality with something different.

Look at the COS (Caché ObjectScript) source for, say, EnsLib.HL7.Service.TCPService to get an idea of how it hangs together. And if you need a custom Adapter to support something that isn't built-in, you can look at the code for those as well (for example, EnsLib.HL7.Adapter.TCPInboundAdapter). This is obviously all done through Studio, and guides for developing using the pre-built adapters are included in the Caché/Ensemble documentation.

Now, if you're talking about an API for some development platform other than COS, that's a different beast.

Jeffrey Drumm · Jun 30, 2017

Are you looking for the Destination file path? That's a Property of the Adapter class. If you need to reference it from within one of the methods you've overridden or have created as a callback, you can  reference it as ..Adapter.FilePath.

If it's the Source file path you're looking for, the only place you'll find that is in pRequest.Source, and that will include not only the path but the filename as well.

Jeffrey Drumm · Jun 28, 2017

If LDAP/AD isn't an option, you should look at the class documentation for Security.Users and Security.Roles in the %SYS namespace. They both have import and export methods that should get  you well on  your way.

You can limit the user export to specific roles, allowing you to synchronize non-administrative users without impacting the administrative ones. Assuming you've created a role named %Users that contains only those accounts that need to be updated across all servers:

%SYS > Set sc = ##class(Security.Users).Export("C:\InterSystems\UserExport.xml",.outcnt,"*","%Users")

This would create the file C:\InterSystems\UserExport.xml, containing the users in role %Users, with a count of the number exported in the variable outcnt. The variable sc is of type %Status and should be 1 if everything went ok.

Those users can then be imported on other hosts using the corresponding import method:

%SYS > Set sc = ##class(Security.Users).Import("C:\PathToImport\UserExport.xml",.incnt)

The number of users imported will be found in variable incnt. Again, sc should be 1 if the method completed successfully.

Jeffrey Drumm · Jun 22, 2017

You could create a custom operation based on EnsLib.HL7.Operation.FileOperation, modifying (or replacing) the value of pFilename used in the outputDocument() method. You can get the specific field value you want to include in the filename with pDcocument.GetValueAt("<some_field_identifier>").

In your specific case, it could be as simple as inserting the following as the first line of the outputDocument() method:

    Set pFilename = pDocument.GetValueAt("MSH:4")_pFilename

Of course, you might want to take the precaution of making sure MSH:4 is actually populated before updating pFilename, and have it do something useful if it's not :)

Jeffrey Drumm · Jun 20, 2017

I've backed out all of the changes that I would have suspected might have an impact, and it's still working (and yes, I've restarted both Apache and Caché). The only thing I haven't yet backed out was the creation of a non-SSL site  on port 8881, but that's something I did early on and am fairly certain I tried an Atelier connection after. But I may be misremembering ...

Jeffrey Drumm · Jun 20, 2017

So, I got it working.

It took a long time, because I missed one very important detail: the trailing backslash on the URL is very, very important. I was testing in my browser with http://oobuntoo.local:8881/api/atelier, which isn't exactly what Bernd and Dmitry told me to do. Since that wasn't working, I wasn't bothering to test Atelier's ability to connect. So somewhere in my flailing around I managed to fix whatever was preventing it from working, and now I need to backtrack through that and figure out what it was.

So ... thanks everyone. I'll mark the right answer as correct as soon as I figure out which one it was!