go to post Scott Roth · Oct 14, 2024 Did you ever find the answer to your question? Did you end up having to use Wireshark?
go to post Scott Roth · Oct 2, 2024 Memory usage. We are seeing a decrease in the amount of available memory under at the OS Level. WRC has mentioned that the gmheap need to be increased in the application, however that is only increasing the amount of memory the application can use, it does not answer the issue of what is using all the memory.
go to post Scott Roth · Oct 2, 2024 There are some details within some of the globals to show us what is causing them to be created, but in my BP I don't get why they are being created. Those that start with $lb(" actually point to the PID within the Application that is being used. The one BPL in question takes the HL7 ADT message and parses it out into separate Insert/Update etc... stored procedures classes to be called against the BO.
go to post Scott Roth · Sep 26, 2024 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.
go to post Scott Roth · Sep 10, 2024 Would suggest you look into moving to VSCode, because Cache Studio is no longer being developed.
go to post Scott Roth · Aug 23, 2024 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.
go to post Scott Roth · Aug 16, 2024 What if you want to use the same Operation for multiple Stored Procedures?
go to post Scott Roth · Aug 13, 2024 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
go to post Scott Roth · Aug 13, 2024 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.
go to post Scott Roth · Aug 12, 2024 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?
go to post Scott Roth · Aug 8, 2024 We are on HealthShare Health Connect 2024.1, no the free version.
go to post Scott Roth · Jul 18, 2024 Correct. the Response from the Stored Procedure was just a %Status.
go to post Scott Roth · Jul 18, 2024 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.
go to post Scott Roth · Jul 18, 2024 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.
go to post Scott Roth · Jul 18, 2024 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....
go to post Scott Roth · Jul 18, 2024 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.
go to post Scott Roth · Jul 16, 2024 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.
