go to post Herman Slagman · Mar 22, 2017 Couple of things I'm not sure of:what is pCompletionKey used for? Can that be used as a unique reference for that invocation of SendRequestAsync?Is there such a thing as a sleep "Status" to use as Quit for OnRequest? Or do I need to loop until done? Will HANG in this case release the resources used by the process?if the target operation responds with an error is that handled by OnResponse or only OnError?The CompletionKey is a 'tag' which you can attach to each async call. So you can distinguish them in the OnResponse by that tag.Just 'Quit' the OnRequest, Ensemble will call the OnResponse when needed.At the end (all Requests have responded or an optional time-out has occurred) the OnComplete will be called.If the target operation has responded with a error-message in the Response message it will be in the OnResponse.(I think) the OnError will be called if the target operation exits with a status code of not $$$OK
go to post Herman Slagman · Mar 17, 2017 using a Command Pipe would be the way to achieve this: Set Command="git status"Set Pipe="|CPIPE|"Open Pipe:(Command:"R"):0If '$Test Return "Cannot open CommandPipe to "_CommandFor { Use Pipe Read Line If $ZEOF Quit Set Lines($Increment(Lines))=$ZStrip(Line,"<>W")}Close Pipe
go to post Herman Slagman · Sep 19, 2016 It's probably more about semantics then syntax, but the correct way of using HTTP methods would be:Create a resource: POSTReplace a resource completely: PUTUpdate one or more properties: PATCH
go to post Herman Slagman · Sep 19, 2016 The obvious answer would be 'it depends' ;-)But essentially that is true, if you want out-of-the box Ensemble supported functionality (HL7, DICOM, etc) then it would be hard to match that within a reasonable time-frame and budget. Also if you want an all-purpose routing engine Ensemble would be hard to beat.But if you have a specific problem in mind, a custom solution could be a better option.IMHO Ensemble's queuing mechanism is pretty dumb, a custom queue could be more intelligent and dynamic, with dynamic actor pools and auto-start/stop queues.Also stuff such as itinerary based routing, true publish and subscribe and complex event processing could then be an option (if needed).And, also important, standard Caché is much cheaper then Ensemble (let alone HealthShare).
go to post Herman Slagman · Sep 10, 2016 It depends on what you want to achieve with FHIR. After all it's an open specification and implemented in (sort of) REST and JSON (or XML).If you only need a limited sub-set and don't need to transform to other formats such as HL7v2/3, or need other parts of HS, then you can easily implement it yourself.
go to post Herman Slagman · Mar 17, 2016 For query parameters you'd use the syntax <url>?param=value, e.g. /appName/customers?lastName=Slagman&gender=MIn your <route> the url would be: <Route Url="/customers" Method="GET" ...And in your method you'd use: Set lastName=%request.Get("lastName")
go to post Herman Slagman · Mar 8, 2016 I assume your interfaces are all part of a bigger application, AFAIK there is no way to span an Ensemble Production across namespaces and from a EIA/ESB point-of-view having separate (connected) productions running on a single Ensemble instance doesn't make much sense.Your idea to have individual builds and deployments makes sense though, but that would be more stuff that a dedicated build/deployment tool should be able to do
go to post Herman Slagman · Mar 5, 2016 Considering myself among the 'the older and more established users of InterSystems technologies' ;-) we've always used the setup where each developer has his/hers own development machine. How the 'sandbox' namespace is called is not relevant. We use Git to tie the stuff together (more and more automated). It is allowed, or even encouraged, to use different versions of Caché or (in our case) Ensemble, which sometimes results in code that is not compatible with the current Production version, but we detect that in our QA phase and that might trigger discussions wether to upgrade Production if a used incompatible feature is of great value.Having a separate development sandbox leaves room for experimenting which you wouldn't have if every developer is working in the same namespace, where in my opninion 'not to step on each others toes' would be much too constraining.It will probable the same when Atelier takes off, some of us will be using that while others will stick to Studio or even brew their own in MS Code.
go to post Herman Slagman · Mar 4, 2016 XSLT in combination with %XML.XSLT.CallbackHandler is an excellent way to extract information from a (large) XML file.We use it to perform XML Shredding and flattening on very large XML.