Hey Yone.

In the first part of your question, you're converting the hexadecimal to Ascii and then attempting to convert the Ascii string to Base64 (giving you "TFgDBAEBAgF5wyYjMTQ1Oz7DunxMWAcIAQEBAhgkWE1M").

The reason you're getting a different result on the Base64 encoding on ObjectScript is because you're encoding the hexadecimal string "4C5803040101020179C3913EC3BA7C4C580708010101021824584D4C" into Base64 without converting it to Ascii first. If you try the hexadecimal string in an online Base64 encoder, you'll see the same output:

Hey Virat.

It's difficult to point you in the direction of documentation that isn't supplied by InterSystems, as the material is generally good and available online. 

The sidebar on the forum has some great links to various resources, and even has a link to a docker image for the community edition (which is free).

If you do look at the community edition, you may find it useful to install the EnsDemo namespace to be able to try a few prebuilt productions and get a feel for things.

Would OS Authentication be of use to you?

When enabled, you should be able to automatically log in based on the OS user account running the script, however you will need an IRIS account with the exact same username as the OS account, and it will need the appropriate permissions in IRIS for what you're looking to do.

Hey Jay.

I appreciate this probably doesn't help you, but thought I would share in case it's of interest to anyone.

I had this same issue with Kaspersky a few years ago when installing a preview of Healthconnect on my local machine to review some upcoming features (Does anyone else remember FHIR?).

As each attempted install would result in an internal virus response and some light hearted ribbing from colleagues, I was quite keen to get this resolved.

I worked with WRC as well as Kaspersky, and we found that the "threat" detected was oddly tied to the build number of Windows 10, and we would not get a detection with the same version of Kaspersky running on different builds of Windows 10 or on any builds of Windows Server Edition we had currently in operation and free to test.

At the time, Kaspersky did state that they had updated their definitions which I confirmed worked, however that could easily have been tied to the specific build of the Healthconnect install exe, or could just be something reintroduced over the last 3 years since I had reported this issue to Kaspersky.

FWIW - if there was something in the installer that was a red flag to all AV suppliers, then I would suspect that it would be addressed (especially as it'd probably flag up with whatever AV is used by Intersystems). However behavior detection isn't an exact science, and I wouldn't be surprised if adjusting the installer to appease Kaspersky is then detected by another supplier as an attempt to avoid detection by an AV.

Hey Sebastian.

I think SetValueAt() is what you're looking for.

The pAction parameter defaults to "set", but I think you can also have "clear", "remove", "insert", and "append".

Just to add an alternative to what has already been offered: you could also use the Data Import Wizard and provide the data in a CSV. You could then insert it into your table quite easily and without trying to built up a 100 union query :)

Hey Nigel.

The key take away from any attempts to backup a running environment is to use freeze/thaw scripts.

The idea being that the backup solution will prompt the IRIS system to freeze the DBs for the backup to take place, and then thaw after the fact.

I recently embarked on this myself, and posted an article showing my journey based on using VMWare and a windows environment. However this should be easily adaptable to other backup solutions.

The only change I have made since that article is that I am not passing the login credentials via a separate file, and instead have OS Authentication enabled within my IRIS system so that the user account running the script is able to automatically authenticate at runtime.

Hey Otto.

If you extend your class with "Ens.Rule.FunctionSet", the ClassMethods contained within will be available as a function for the DTL:

Hey ED Coder.

You should be able to just use the EnsLib.HL7.Service.HTTPService class for your Service, and then the request can be sent to the port you define as you would for any other HL7 inbound. You can also then specify the message schema in the same way. 

The "url" you provide can be the IP of the machine with the port afterwards. For example, I just set up an inbound on a dev environment and then sent a message from Insomnia.

I sent it as a post to http://IP:PORT with the HL7 message as the content of the HTTP body:

I've cobbled the following together from other posts that come close to this (for example, here and here) and running each line in terminal should disable all the services from the production in the namespace you run it in:

zn "NAMEOFNAMESPACEHERE"

Set tRS = ##class(%ResultSet).%New("Ens.Config.Production:EnumerateConfigItems")

Set tStatus = tRS.%Execute("Production.Name.Here", 1)

While tRS.%Next(.tStatus) {set sc = ##class(Ens.Director).EnableConfigItem(tRS.%Get("ConfigName"), 0, 1)}

Line 1 sets your namespace, 2 and 3 bring back the list of services (the flag set to 1 on the third line specifies listing the services, setting this to 3 will bring all operations)

Line 4 is a while loop to iterate through the result set and to then use Ens.Director.EnableConfigItem to disable the config item by name (flag 1 is the enable/disable flag, and the second is to tell it to update the production).

This could probably be made nicer and more efficient (eg. disabling all of the config names without updating the production and then updating the production once using "##class(Ens.Director).UpdateProduction()" to avoid doing it once per entry) however I hope it works as a starting point.

I believe that the HL7 Router which you are using to send to the operation should have a configuration item for setting the response target (called ResponseTargetConfigNames).

So the route the message would take is: