I did open a ticket with WRC but in investigating it on my end we think a network outage on the 9/19 caused some of our interfaces to go into a loop that took the Shared Heap Memory to the max, which could have caused the issues with connecting to LDAP.
Would suggest you look into moving to VSCode, because Cache Studio is no longer being developed.
Were you ever able to figure this out?
What do you suggest I use instead?
Yes, the "xxxxxx" represent the SQL Connections, however we must maintain 3 different connections as there are 3 different environments we send data to in MS SQL.
Yes, the code should be the same, but there are times where we are testing things in DEV before they go to the TEST MS SQL environment.
Modifying the SQL Connection String at the System level isn't as logical.
I thought it would be easiest to define the Linked Stored Procedure once and just update the Connection String within the Object Script when I was ready to move it to a different MS SQL Environment.
What if you want to use the same Operation for multiple Stored Procedures?
There are still many features and workflows that are flawed in the new editor. My team opted to go back to the old editor for now.
Business Rule Editor Changes | InterSystems Developer Community | Business
While it is nice to have, like other have said it still is learning and lacking. The responses weren't as fast as one would expect, but maybe my questions were too complex for it.
I am not using a batch header in the Record Map but is there a way to get the field descriptions as well. Right now, when I look at the field, it is the field value, but I need to get the name as well to define as part of the FHIR query. Is there a way to do that as well?
2022.1.4
We are on HealthShare Health Connect 2024.1, no the free version.
Correct. the Response from the Stored Procedure was just a %Status.
Does your Java Gateway stop or your BO? Is something scanning the ports and causing a blockage, or failure perhaps? Try enabling the Java Gateway log file, I know it's hard to read, but it may give you a clue to what is going on.
Also make sure that the External Language %JDBC Server isn't crashing for some unknown reason. I found that if the %JDBC Server starts having issues that the Java Gateways within your Namespaces start having issues as well.
I had a context variable set to Ens.Response, then when I would make my calls to the BO to execute the Stored Procedure on MS SQL, I would set the Response even though I did not expect thing to Ens.Response and my context variable to callresponse.
Then return Ens.Response at the end of the BP. I figured since it was blank it was not needed and would be creating additional Ens.Response objects.
So I removed the callresponse from those calls that I did not expect anything back from like inserts, etc... because if there was a SQL error the status and error would of be sent back to the BO anyway.
I was sending callresponse objects back to Ens.Response, but ended up removing those since I was not capturing any response from our JDBC Microsoft SQL Stored Procedure calls.
You can't leave the Response blank in the settings on the BP, so while not ideal Ens.Response might be created.
Just my experience. Unless anyone has any other suggestions....
In my adventures, I broke down our BPL's to see where the Custom Message Classes were leaving the Orphaned messages.
Within BPL's make sure if you use Context Variables none of them are sent to "Instantiate", if you end up not using that context variable it will leave a blank (orphaned) message.
Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it.
I also took it upon myself to make sure any context variable (message class) that I defined, I set to "" after using it.
Have you checked to see if there is another app using the Port? I know that sometimes the Shutdown doesn't always shutdown the Java Gateways properly, especially if you failover, and fail back to the primary. We have it scripted to make sure that if a Shutdown occurs or if the mirror fails over that the Java Gateways are properly shutdown.
In this post https://community.intersystems.com/node/539431 from Apr 6, 2023, @Mark.O'Reilly9949 mentions building a custom function to Purge Custom Messages using a Data Lookup table. However, it does delete by message count and not by days, which is something I am not fond of, and I haven't been able to get it to work for our needs either.
I know it's been a while, but most DTL's create a Target EnsLib.HL7.Message.%New(), so are you saying that is flawed?
Thanks for adding to the ongoing list. Make sure you open a WRC ticket to make InterSystems aware of the likes/dislikes..
I am not sure if SSRS can handle JDBC connections.
Using the following within a Code action I got no errors...
set tPatient = $CLASSMETHOD("HS.FHIRModel.R4.Patient","fromDao",tRawJSON)However as soon as I tried it within a Set action in the DTL I got errors...
.png)
| ERROR <Ens>ErrBPTerminated: Terminating BP TEST_FHIR_PATIENT_SEARCH # due to error: ERROR <Ens>ErrException: <UNDEFINED>%Construct+1 ^osuwmc.Demo.FHIRPlace.BPL.FHIRDataCollector.Context.1 *HS -- logged as '-' number - @' Set i%%Concurrency=$zu(115,10),i%%LastError=1,i%tPatient=HS.FHIRModel.R4.Patient' > ERROR <Ens>ErrException: <UNDEFINED>%Construct+1 ^osuwmc.Demo.FHIRPlace.BPL.FHIRDataCollector.Context.1 *HS -- logged as '-' number - @' Set i%%Concurrency=$zu(115,10),i%%LastError=1,i%tPatient=HS.FHIRModel.R4.Patient' |
if I go back to using the Code action, how can I guarantee that tPatient gets into the target?
Because Intersystems is already trying to parse the message and field as it determines which DocType the message falls under, I would say that there needs to be a Preprocess involved to remove the extra line break. Whether that needs to be a custom Inbound HL7 Business, or some other type of scripting that is up to you.
Can you call GetAuthorizationToken even though you aren't using OAuth?
Other issues that we have noticed are..
I have sent this feedback to InterSystems.
From my testing in Postman, the JWT that is sent back has an "expires_in" included in the response.
{"access_token":"...........","token_type":"bearer","expires_in":"3600"}Thats what I thought, so since it is not how do I verify the token is expired? or should I just get a new token every time?
The Payload needs to have the username which is an email, and the password.
POST /v2/login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
email=test%40test.com&password=test123
This is all relatively new to me, so please bear with me. Since I am getting a Token it's not the same as OAuth, correct? Nothing in the Vendors documentation says that it is OAuth, it just says..."Authentication method is a token-based approach".
So, if that is the case, I can't use the %SYS.OAuth2.AccessToken methods to verify IsAuthorized, and GetAccessTokenClient correct?
Robert is correct, more detail is needed. However, as an example, we take HL7 messages and using specific structure classes to match stored procedures, we send calls to an EnsLib.SQL.OutboundAdapter using JDBC to update, insert, and query MS SQL.