Just wanted to give an update on option "b" in this comment, in case anyone reads this going forward.
I think at one time ^%ISCLOG was used to both set the log level and store the log data. Now ^%ISCLOG is only used to set the log level. The log data is stored in ^ISCLOG (no "%") in the %SYS namespace. So instead of doing:
zwrite ^%ISCLOG // This is no longer the log global!!
You would instead do:
In the %SYS namespace. (Or look at it in the Management Portal, I find it much easier to read that way.)
I couldn't find anything in the docs on ISCLOG specifically, but it is mentioned in the context of other subjects, for example:
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-h...
One thing I noticed when I tried running your JS code is that if I replace:
var signatureBytes = CryptoJS.HmacSHA256(signature, secretByteArray)
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 $ZCVT(str, "I", "UTF8")
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.
Log in or create a new account to continue