Reviewing the different articles that I have published, I realized that I needed to explain a very practical functionality within our EMPI (Enterprise Master Patient Index) and it is none other than the notification of registrations and links to systems external to the EMPI.
I have a rest API Class used for getting data from Cache 2018 version. I have single route '/callfuntions' I send the following parameters to the API :- className, methodName, params I use $CLASSMETHODto execute and send the result back to the client.
If I make more that 10 to 12 requests in quick succession, then it stops sending data.
I am writing to express my interest in the "IRIS Ensemble Integration . I have 2 years of experience as an Ensemble IRIS Developer, working with Ensemble and IRIS for integration, server management, and application development. Looking for more opportunites to work under Iris Cache Objectscript
The aim of this article is to explain how to create messaging between IRIS and Microsoft Teams.
In my company, we wanted to monitor error messages, and we used the Ens.Alert class to redirect those error messages through a Business Operation that sent an email. The problem was that we sent those error messages to a support account where there were many emails. We wanted something specific for a specific team.
So we investigated how to make these messages reach the development team directly and they could have, in real time, a notification of an error in our production. In our company we use Microsoft Teams as a corporate tool, so we asked ourselves: How could we make these messages reach the IRIS development team?
If anyone has a custom checklist of tasks that must absolutely be done when doing this upgrade to make sure everything is included and nothing is lost or destroyed, we would greatly appreciate it? We have the generic checklist provided on the support websites but we run custom build classes, ftp, tcp-ip, batch, etc.
For background, I've developed code that relies on %JSON.Adaptor functionality across an entire package of classes in our codebase. In regenerating these classes with %JSON.Adaptor as a superclass, I've encountered compilation errors from the JSON adaptor generators in certain classes, triggered by certain property types or parameters that are incompatible.
Is it possible to retrieve/find all the names of subroutines, procedures, or functions from a deployed routine?. in the routine below, how can I extract names like x2 and execsql? I’ve just tried using openId on %RoutineMgr but it didn’t help.
I have recently had the intersystems healthshare software installed on the laptop - but do not have the credential to log into the management portal. Is there anyway to recover these for the users _system or Admin or SuperUser?
Do you have HL7® V2 messages that you need to convert to the HL7® FHIR® format for better integration and analysis? See how the InterSystems FHIR Transformation Service can help:
We are attempting to send HL7 messages over to CBOARD NetMenu over HTTP using SSL. We set this up using the EnsLib.HL7.Operation.HTTPOperation adapter. When we attempt to send the message we are receiving
MSH|^~\&|||DIETOE|A6M0|202505131437||ACK^HTTP^415|00|P|2.1 MSA|AE|9165602|HTTP (N)ACK 'HTTP/1.1 415 Unsupported Media Type'
I am attempting to implement continuous integration using Docker with Caché 2018.1, and I am in the process of creating an image for our client. I have already installed Caché 2018.1 on the RedHat server, but I am working on a script to create the database and namespace. For the database, I used the following code:
🗣 Presenter: @Evgeny Shvarov, Senior Manager of Developer and Startup Programs, InterSystems
https://www.youtube.com/embed/Oo4OBfTf4d4 [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
I have a problem with the deployment. When I deploy using the Ens.Deployment.Deploy class, I no longer receive the logs in the terminal. However, the deployment went well, I see it in the history on the portal.
It works on our environment, but not on the client's.