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 19, 2016 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,! } } }
go to post Herman Slagman · Sep 18, 2016 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 Herman Slagman · Sep 18, 2016 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 Herman Slagman · Sep 10, 2016 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 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 · Sep 4, 2016 Mike,Please elaborate. What do you mean by an 'extract' from a database.JSON is about data, not classes or methods.
go to post Herman Slagman · Aug 26, 2016 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 Herman Slagman · Aug 26, 2016 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 Herman Slagman · Aug 26, 2016 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 Herman Slagman · Aug 26, 2016 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 Herman Slagman · May 9, 2016 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 Herman Slagman · May 9, 2016 Interesting article, but where have the pictures gone ?I remember seeing a version which had them, was that another resource ?
go to post Herman Slagman · Mar 19, 2016 I'm afraid this will have to be a WRC call: how to get to query parameters in EnsLib.REST.ServiceI 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 Herman Slagman · Mar 18, 2016 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 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 15, 2016 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 Herman Slagman · Mar 14, 2016 We use an XSLT utility to merge the two Productions, where the existing 'Production' Propduction has prevalence.
