Can you be more specific about how your implementation isn't working?  For example, do you have a known signature for known inputs that you are comparing against?  Or is there some external system you are trying to authenticate to?

When I ran your IRIS code (hardcoding values for requestTimeStamp and nonce), the tSignature value matched the output of this tool: https://www.freeformatter.com/hmac-generator.html#ad-output

("to_hmac" is not a valid variable name in ObjectScript, but I assume that's a copy-paste error.)

I wasn't familiar with the CryptoJS library before looking into this, but in the examples I was able to find, it looks like the 2nd arg to HmacSHA256() is typically passed in as a string, rather than a byte array: https://www.jokecamp.com/blog/examples-of-creating-base64-hashes-using-…

One thing I noticed when I tried running your JS code is that if I replace:

var signatureBytes = CryptoJS.HmacSHA256(signature, secretByteArray)

With:

var signatureBytes = CryptoJS.HmacSHA256(signature, APIKey)

Then then value of requestSignatureBase64String in your JS example matches the value of tSignatureBase64 in your IRIS example.

So my guess is that you're getting the correct raw signature value in IRIS, however in your IRIS example you are using the hex representation of it while in your JS example you are using the base64 representation.  Also, if you are using your JS example for reference, you may want to look into the expected format of the 2nd arg to HmacSHA256().

Without being able to see your environment, it's difficult to say where the disconnect is or what would need to be tweaked to decode those characters correctly.  However, if you have an opportunity to manually process the HL7 data at any point as it flows through the system, then you may be able to call $ZConvert/$ZCVT on the encoded data to decode it:

USER>s str = $C(90,111,108,195,173,118,97,114,101,115)
 
USER>w str
Zolívares
USER>w $ZCVT(str, "I", "UTF8")
Zolívares
USER>

https://docs.intersystems.com/iris20212/csp/docbook/Doc.View.cls?KEY=RC…

However, there should be a way to specify to your business service the encoding of input data so that it can decode the data for you.  I would have thought that this would be done with either the "Charset" or "Default Char Encoding" settings, but it sounds like you've already tried that.  I'm not sure why this wouldn't be working, but I'm fairly confident that this is how encoded data is supposed to be decoded, so it may be worth another look.

Hi Carl, To expand on Tim's answer:

Keys in the HS Configuration Registry can either be set by a user in the Management Portal, or they can be set programmatically.  I am only seeing one place in the HS codebase where these keys get set, in HS.Util.Installer.Kit.IHE.XDM.Direct:AddHub():

Do ##class(HS.Registry.Config).AddNewKey("\ZipUtility\ZipCommand",$S($zv["Win":"""c:\program files\7-zip\7z"" a %1 . -r",1:"zip -rm %1 ."))Do ##class(HS.Registry.Config).AddNewKey("\ZipUtility\UnZipCommand",$S($zv["Win":"""c:\program files\7-zip\7z"" x %1 -o. -r",1:"unzip %1 -d ."))

However this class appears to be related to setting up support for the XDM IHE profile, so unless that is something that's important to you, you shouldn't worry about getting that code to run.  Rather, this is just an example of the values for these keys that is expected by the code that uses them.

Hi Bill, I was facing a similar (but not identical) issue not too long ago where I was trying set %response.Status in my REST handler class, only to have a different status code reflected in the response to the client.

The issue ended up being that the request to the REST handler class that I was working on was being forwarded from another REST handler class that extends EnsLib.REST.Service rather than %CSP.REST.  The EnsLib REST handler works a little differently.  The user code is supposed to write the output to a response stream, with the response headers being set as attributes of the stream, rather than setting headers of %response directly.

So my question is, is your REST handler downstream from an EnsLib.REST.Service REST handler?  I also see that your REST handler extends Ens.BusinessService.  I wonder if something in that class is overriding your %response headers.  Is there any way you can test your class with that superclass removed?

I'm not sure in what version %JSON.Adaptor was introduced, but if it's in your version, you can have the class modeling your object extend %JSON.Adaptor, which will give you access to the %JSONImport() method, which can de-serialize a JSON payload into an object.

One caveat to this is that I believe any serial objects referenced by the top-level object will also need to extend %JSON.Adaptor for the import to work properly.

I tried to use one of the "GetStored" methods of %Dictionary.MethodDefinition (specifically, "DescriptionGetStored") and got a "<METHOD DOES NOT EXIST>" error.  I suspect this is because this class has "StorageStrategy=custom".  So if a class specifies a custom storage definition, does that mean these methods won't be auto-generated?

Hi, with regard to your second question, if your property "CODE" is unique and indexed, ie, your class definition includes something like:

Index CodeIndex on CODE [Unique];

 Then there is a generated method you can use to open the object that has CODE=Xparameter:

set myObject = ##class(User.MyPersistentClass).CodeIndexOpen(Xparameter, concurrency, .sc)

For any unique index, the method name is always "[index-name]Open".  You can read more about auto-generated methods here:

https://community.intersystems.com/post/useful-auto-generated-methods

With regard to your first question, I'm not aware of any system method that returns a list of all saved objects for a class, but you could implement that by creating a class method that creates and executes the appropriate query, then iterates over the results and copies them to a list.  I would be cautious about doing something like this with large tables though, since you would essentially be loading the entire table into memory.  This could lead to <STORE> errors:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RERR_system

A better solution might be to implement some kind of iterator method that only loads one object at a time.

How about saving the values of a, b, and c in whatever way makes sense given the context - global, PPG, %-var, %session, or have the method return them, and then also make them arguments to the method.  When calling the method again, check for them in whatever way they were saved, and if not found initialize them to "".

If you do find them, you might have to "rewind" each subscript by one to make sure you don't miss anything, which is easy to do with $ORDER:

set a = $ORDER(^data(a), -1)

How is the client report being generated?  Would it be possible to implement this as a Zen Report?  That might allow you to embed the image in the report and specify its size within the report.

Hi Krystian, are you referring to the "extension" property in the data model?  If so, then that is currently supported by FHIR repository in HealthShare.  Resources can be created in the repository with extensions and these will be saved.  I'm attaching an example of a patient resource that contains multiple extensions. Note that this is a DSTU2 resource, which is the FHIR version that HealthShare currently supports.  The current version of FHIR is STU3.  HealthShare will support this in a future release.

EDIT: I *thought* I could attach a file, but that seems not to be the case. In any event, you can download the FHIR DSTU2 examples directly from the hl7.org site as XML or JSON:

http://hl7.org/fhir/DSTU2/examples.zip

http://hl7.org/fhir/DSTU2/examples-json.zip

And you can look through those for examples of extensions.

Hi Tom, can you describe how you created the FHIR namespace? Also, I'm pretty sure the version of HSCore you're using is 15.03, but could you also include the full version string, for future reference?

My guess is that you are trying to interact with a FHIR Gateway namespace, which does not support the create interaction from clients.

Basically, HealthShare currently supports two types of FHIR namespaces.  The first is a regular FHIR reference server, that supports most of the FHIR DSTU2 standard, including create, read, update, delete, search, history, and vread interactions.  However, this server is not a part of the HealthShare federation in any way.  It neither sends data to nor receives data from the rest of HealthShare.

The other type of FHIR namespace is what is known as a FHIR Gateway.  Clients interact with it by first starting a session (there are different ways of doing this), then, within that session, loading a patient's data from the HealthShare Information Exchange into the FHIR Gateway by doing a read on that patient (where ID=the patient's MPIID from Information Exchange).  Then queries that are explicitly scoped to that patient via search parameter may be submitted to the FHIR endpoint.  Clients may not create resources on the FHIR Gateway.  Data can only be loaded into the FHIR Gateway from Information Exchange.  Clients can only see data in their session, and after a session ends, any data in that session is physically deleted.

You can find more information about the FHIR Gateway in the HealthShare documentation:

http://<host>:<port>/csp/docbook/DocBook.UI.Page.cls?KEY=HESUP_fhir

Or, if you have any specific questions, I'd be happy to answer them here.

"The only reason I can think of, why we do this, is to ..."

I can think of one other reason for this pattern, that is perhaps better illustrated if we think of "Film" as a code table, and change the name of "CinemaFilm" to something like "Showing".  In the entire world there is only one movie called "Wonder Woman", released in 2017, and starring Gal Godot.  So rather than reproducing this object thousands of times for every cinema that happens to be showing this movie, the object exists once in the "Film" code table,