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).
Set Sub1="" For { Set Sub1=$Order(^Trans(Sub1)) If Sub1="" Quit Write Sub1,! Set Sub2="" For { Set Sub2=$Order(^Trans(Sub1,Sub2)) If Sub2="" Quit Write ?3,Sub2,! Set Sub3="" For { Set Sub3=$Order(^Trans(Sub1,Sub2,Sub3)) If Sub3="" Quit Write ?6,Sub3," = " Set Data=(^Trans(Sub1,Sub2,Sub3)) Write Data,! } } }
That being said I wonder what ISC strategy/policy will be in the future.
Cache and Ensemble are in the 'Platform division', HealthShare in the 'Healthcare division'.
HL7v2 is traditionally supported by Ensemble that won't change, but the rumour is that all health related features and products will be in HS only (e.g. FHIR).
Does this mean that health related Ensemble implementations will have to upgrade to HS eventually ?
I doubt if it makes sense having Caché on the Pi. It's just too heavy. Supporting different IoT protocols on the server (as a hub or controler) makes more sense to me.
With MQTT, ZWave, ZigBee, gRPC adaptors Ensemble could well be the controller to control then all ;-)
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.
It's a little confusing: you want to do integration tests with a unit test framework, that doesn't sound right.
I'm not a big fan of unit testing, but for integration tests you'll need mockup services to emulate the 'outside' world. We use Soap Sonar, SoapUI and Cache services to just do that.
What would be example business cases that require more then one projection of a class ?
If the adaptor would provide both a JSON string and an JSON object, you could manipulate the object in order to get a different projection.
Our JSON implementation did just that, 99% the default one was used, but if we needed some more filtering of certain properties they could be removed (or added for that matter) from the object and then transformed to a JSON string.
I think that ISC should have implemented the JSON support for existing classes the same as they've done for XML. Through a mixin adaptor class and accompanying property class. That way the projection to JSON is far more controllable.
I opposed strongly against the naming conventions used in the $-systemMethods so I should be happy.
But facing such a backwards incompatibility in 2016.2 makes me very sad. We've planned several major new features in our application all using REST and JSON to be released on 2016.1 very soon. Now we have to review a lot of code and try to decide what to do with them in order to be compatible with future releases. I don't like the suggested macro solution, but it might be the only viable way. We might even switch back to our own JSON implementation which we have used for years.
The most important other issue I opposed to is the interface of the Dynamic array, it is not compatible with the existing COS %Collection interface. Is there any change that will be 'fixed' too ?
I'm sorry, I missed the Ensemble part. I was referring to the %CSP.REST class. I don't know what version of Ensemble you use, but at least in 2015.1 it seems that the Enslib.REST.Service doesn't copy the %request.Data values (the query parameter values) into the attributes of the pInput stream.
But at least they should be available to you in the %request.Data array (accessible by %request.Get(var)), why that is the case in your situation I can't see, it has got nothing to do with your method, but somewhere 'upstream'.
go to post
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
For {
Set Sub1=$Order(^Trans(Sub1))
If Sub1="" Quit
Write Sub1,!
Set Sub2=""
For {
Set Sub2=$Order(^Trans(Sub1,Sub2))
If Sub2="" Quit
Write ?3,Sub2,!
Set Sub3=""
For {
Set Sub3=$Order(^Trans(Sub1,Sub2,Sub3))
If Sub3="" Quit
Write ?6,Sub3," = "
Set Data=(^Trans(Sub1,Sub2,Sub3))
Write Data,!
}
}
}
go to post
That being said I wonder what ISC strategy/policy will be in the future.
Cache and Ensemble are in the 'Platform division', HealthShare in the 'Healthcare division'.
HL7v2 is traditionally supported by Ensemble that won't change, but the rumour is that all health related features and products will be in HS only (e.g. FHIR).
Does this mean that health related Ensemble implementations will have to upgrade to HS eventually ?
go to post
Hi Mike,
I really appreciate your Newbies work, but I wouldn't use the Do <space><space> dot syntax.
It's a very obscure syntax, only used in Mumps. Using 'traditional' For-loops is much more in line with what today's programmers would expect.
go to post
I doubt if it makes sense having Caché on the Pi. It's just too heavy.
Supporting different IoT protocols on the server (as a hub or controler) makes more sense to me.
With MQTT, ZWave, ZigBee, gRPC adaptors Ensemble could well be the controller to control then all ;-)
go to post
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
Mike,
Please elaborate. What do you mean by an 'extract' from a database.
JSON is about data, not classes or methods.
go to post
It's a little confusing: you want to do integration tests with a unit test framework, that doesn't sound right.
I'm not a big fan of unit testing, but for integration tests you'll need mockup services to emulate the 'outside' world. We use Soap Sonar, SoapUI and Cache services to just do that.
go to post
What would be example business cases that require more then one projection of a class ?
If the adaptor would provide both a JSON string and an JSON object, you could manipulate the object in order to get a different projection.
Our JSON implementation did just that, 99% the default one was used, but if we needed some more filtering of certain properties they could be removed (or added for that matter) from the object and then transformed to a JSON string.
go to post
I think that ISC should have implemented the JSON support for existing classes the same as they've done for XML. Through a mixin adaptor class and accompanying property class. That way the projection to JSON is far more controllable.
go to post
I opposed strongly against the naming conventions used in the $-systemMethods so I should be happy.
But facing such a backwards incompatibility in 2016.2 makes me very sad. We've planned several major new features in our application all using REST and JSON to be released on 2016.1 very soon. Now we have to review a lot of code and try to decide what to do with them in order to be compatible with future releases. I don't like the suggested macro solution, but it might be the only viable way. We might even switch back to our own JSON implementation which we have used for years.
The most important other issue I opposed to is the interface of the Dynamic array, it is not compatible with the existing COS %Collection interface. Is there any change that will be 'fixed' too ?
go to post
Ah, I found it !
It's the CSC Proxy that denies access to the pictures.
I must have read it before from home.
go to post
Interesting article, but where have the pictures gone ?
I remember seeing a version which had them, was that another resource ?
go to post
I never knew he was that sexy :-P
go to post
I'm afraid this will have to be a WRC call: how to get to query parameters in EnsLib.REST.Service
I don't know why the %request doesn't hold the query parameters, maybe it's not even the same request that actually entered the application.
go to post
Congratulations John !
You really deserved it.
go to post
I'm sorry, I missed the Ensemble part.
I was referring to the %CSP.REST class.
I don't know what version of Ensemble you use, but at least in 2015.1 it seems that the Enslib.REST.Service doesn't copy the %request.Data values (the query parameter values) into the attributes of the pInput stream.
But at least they should be available to you in the %request.Data array (accessible by %request.Get(var)), why that is the case in your situation I can't see, it has got nothing to do with your method, but somewhere 'upstream'.
go to post
For query parameters you'd use the syntax <url>?param=value, e.g.
/appName/customers?lastName=Slagman&gender=M
In your <route> the url would be:
And in your method you'd use:
go to post
I totally agree with you Bill.
ISC is doing a great job of being backwards compatible. Even deprecated features are supported for a long time.
There's plenty of time to phase those out.
go to post
We use an XSLT utility to merge the two Productions, where the existing 'Production' Propduction has prevalence.