go to post Julian Matthews · Apr 18 Thanks Nick. Having done some tests (and reading the link shared), the table locking still allows SELECT statements to be executed so the objectscript locking will be my approach.
go to post Julian Matthews · Apr 16 Hey Scott. I saw this post when you originally made it, and I was curious to know what direction you went with?
go to post Julian Matthews · Apr 9 Thanks for sharing this Neil - I hadn't considered the benefits of mapping the credentials and the subsequent SecondaryData, and is an approach I will be looking at going forward.
go to post Julian Matthews · Apr 5 As a short term approach, you may want to look into using Stunnel in client mode to encrypt the traffic and then set something up similar to: This would mean that the traffic between your 2016 instance and stunnel is unencrypted but all on the same machine, and then stunnel handles the encryption between your machine and the external site using TLS1.3. However, even if you go this route, I would still recommend getting the process started for upgrading to a newer version.
go to post Julian Matthews · Feb 2 Increasing the pool value will have some effect on the RAM and CPU usage, but no different than having other jobs running through the production. If you move all the components over to using the actor pool (by setting the individual pool settings to 0) it should be easy enough to raise the value bit by bit while keeping an eye on the performance of the production and the cpu/ram usage of the machine to find a sweet spot. If the API just needs a bit of extra resource when there's a small spike in the inbound requests, then this should not be of too much concern as it will just calm down once it's processed what has been requested. If, however, there's a chance that it could be overloaded from inbound requests and the worry is that the server won't cope, then maybe look at using Intersystems API Manager to sit in front of the environment and make use of things like the rate limiting feature. Or you could go even further and begin caching responses to return if the API is being queried for data that isn't changing much so that there's less processing being done for each request if it's going to get called for the same information by multiple requests in quick succession. You could make your own solution with caché/Iris, or look at something like redis.
go to post Julian Matthews · Feb 2 I'm thinking to increase the pool parameter, but I'm not sure if it's a good idea. If you are not concerned about the order of which you are processing the inbound requests, then upping the pool size to the number of parallel jobs you're looking to run with should do what you need However, you may need to then also apply this logic to related components that the Process interacts with, otherwise you will end up just moving the bottleneck to another component. Alternatively, if it fits your use case, you could use the Actor Pool for your production components and then increase it to a point where you see the bottleneck drop off. Paolo has provided the link to the documentation on Pools, which has some info on considerations for the use of the two different types of Pool.
go to post Julian Matthews · Dec 22, 2023 Hi Nimisha. I see what you mean now. It does seem like the code within a code block doesn't have access to the methods from Ens.BusinessProcess. I suspect your only option for is to use the "Call" activity set to synchronous with a "Sync" after it.
go to post Julian Matthews · Dec 22, 2023 Thanks Luis. The issue I'd have is that the clock starts on the poll interval at the point the service is started, so a restart of the server/production would then shift the time of day it tries to run, which would not be ideal if I needed a single run at a specific time of day. I might try a combination of the large poll interval and defining a schedule (based on the other responses) and see if that has the desired effect, but I may need to just concede and continue using the task manager. 🙂
go to post Julian Matthews · Dec 22, 2023 Are you able to share the full error you're seeing? I have just tested this, and I'm getting no such errors when compiling.
go to post Julian Matthews · Dec 21, 2023 Hi Mary - thank you for your reply. Unfortunately the Schedule Option isn't suitable where we need the job to run only once at a set time per day. And, our current solution is very similar to the accepted answer from Ashok Kumar, which is what I was hoping to simplify in some way.
go to post Julian Matthews · Nov 8, 2023 This may cause some regions to opt for FHIR as a response while others opt for other solutions such as OpenEHR. There's no reason for these to be seen as competing standards. A model where the data storage is OpenEHR and the data transfer is FHIR is seen by some as the best of both worlds 🙂
go to post Julian Matthews · Oct 11, 2023 I'm not sure there's a way to select it when creating a production export. The data in stored within the Global "Ens.Config.BusinessPartnerD" which you could export separately and then import into your new environment?
go to post Julian Matthews · Oct 11, 2023 I haven't seen anything "official" but there was this article from 2021 that provided a way to recreate it: VSCode Tips & Tricks - SOAP Wizard | InterSystems Developer Community |
go to post Julian Matthews · Sep 22, 2023 Hey Christine. If I'm reading your question and subsequent replies correctly, you're trying to take the value of PV1:7.1, and then use that in a SQL query. The answer has been given by Ashok when you put their replies together, but hopefully putting it all into a single response will make things easier to follow. If this is the case, then you will want to do the following: Step 1: Set a variable to the value of PV1:7.1: Step 2: Add a code block, and use this to run your sql query: Step 3: Do what you need to with the value of ID - for the sake of this response, I'm just setting the value of PV1:7.2 to the ID returned from the query that inserted into the variable "Output": It's worth knowing that, when working with Embedded SQL, prefixing a variable with a colon is how you can pass variables in and out of the Embedded SQL section of code. However it's a bit clearer when working directly with ObjectScript vs a DTL. For example, if we had the following table: ID COL_A COL_B 1 ABC 123 2 DEF 234 We could have the following in ObjectScript: Set X = "" // X is null Set Y = "ABC" &SQL( SELECT COL_B into :X From TestTable WHERE COL_A = :Y ) WRITE X //X is 123
go to post Julian Matthews · Sep 21, 2023 I don't believe there is a way of increasing the system limit on string lengths. Even if there is, it's best to approach this by working with the data as a stream. Otherwise you could end up in a cat and mouse game of needing to increase the length the next time you get a larger document
go to post Julian Matthews · Sep 20, 2023 The input is a string, so the max length will be your system max (which should be 3,641,144). Assuming you're trying to retrieve the stream from a HL7 message, you will probably want to use the built in method GetFieldStreamBase64 So you could try something like: Set tStream = ##class(%Stream.TmpBinary).%New() Set tSC = pHL7.GetFieldStreamBase64(.tStream,"OBX:5") And then your decoded file would be in the temp stream. (You may need to tweak this slightly depending on how you intend to then use the stream, and the correct property path of the Base64 within the HL7 message)
go to post Julian Matthews · Sep 14, 2023 Stupidly, no. As the default was set to "TEST" in my function, it worked fine throughout testing. Once the upgrade to Prod occurred, the issue was spotted, and the simple solution was to just reset the values. As I was moving from an adhoc to a official release, I chalked it up to that. Next time, WRC will be getting a call 🙂
go to post Julian Matthews · Sep 14, 2023 Word of warning for using this - I have had this value be reset during an upgrade on Healthconnect. I was using this value in a function to control the output of a Transform, and I hadn't accounted for the chance of this returning null. My code looked something like this: ClassMethod WhatEnvAmI() { Set Env = $SYSTEM.Version.SystemMode() If (Env = "LIVE")||(Env = "FAILOVER"){ Quit "LIVE" } Quit "TEST" } So, post upgrade, the transform suddenly begun outputting values specific to the test system from the live environment.