There is nothing wrong with escaping a Solidus character. The JSON specification states that a Solidus "may" be escaped but does not have to be. You should find that most decoders will unescape the Solidus correctly, so you could just leave it as is.
$find is marginally quicker than the contains operator with a million operations in .004609 seconds, whilst the other two methods are relatively slower. I say relative because they are still quick in their own rights.
A wider question might not be which is the fastest, but how it's implemented with multiple tag tests. For instance a single variable creation is almost as expensive as the string test itself, and if you wrapped it all in a re-usable method, the method call would be 10x as expensive.
If you are dealing with two strings in the first instance, then a tight loop on $find is going to be your most optimum option. The other functions are probably just as performent in the right context, but if you have to dissect the strings to implement them, then the cost is not the test, but in the other operations that you have to do first.
A "Web Service" is just a generic term for an electronic service that operates over HTTP.
SOAP and REST can both be considered as a web service. Whilst SOAP is a protocol, REST is just an architectural style that operates over HTTP.
The NPI registry API can also be considered a web service, but it's clearly not SOAP, and it doesn't really conform to a REST architecture style either.
In fact if you look at the demo page you realise that the API is actually just a simple HTML form submit handler where the form values are sent in the GET request, as you can see here it submits all of the form values even if we provide just one form value...
You don't need to use a REST client library to work with this API, here is a simple command line demo just using the standard %Net library - I had to create an empty SSL/TLS configuration in the management portal named npiregistry as this needs to work over SSL.
Which tells us that k1 is being used but has not been initialised.
Set k1=request.GetNextIndex("PIDgrpgrp("_(1)_").ORCgrp()",k1,.tSCTrans)
/\
UNDEFINED
Without the source code its a little hard to see how your are implementing this.
If this is your own code block then you could initialise k1 first
Set k1="" Set k1=request.GetNextIndex("PIDgrpgrp("_(1)_").ORCgrp()",k1,.tSCTrans)
Alternatively, if you make k1 a context property then I believe it will initialise it for you.
Seems like a simple task to crack with a BPL sledgehammer. If there is no other BPL logic then you might want to consider just using a simple custom process, or via an HL7 routing rule with your own custom function
You shouldn't trust variables populated with embedded SQL.
You need to check the SQLCODE value to make sure you have actually found data, if SQLCODE=0 trust the data, if SQLCODE=100 the query didn't find any data, any other value should probably throw an error as there will be a problem with the query.
Assuming you don't have escaped characters in the first or second field, you can just paste the following three lines into the terminal.
set file=##class(%Stream.FileCharacter).%New() do file.LinkToFile("c:\Temp\file.csv") for quit:file.AtEnd set ^People("Customers", "Acc.division",$zstrip($piece(file.ReadLine(),",",2),"<>W"))=""
You will end up with a global that looks like this...
go to post
Hi David,
The ruleset including assign actions are evaluated before the send actions.
In this instance, if both rules are true then the first assign will be overwritten by the second assign, before both send actions are processed.
I guess you could work around this by having two different property names and testing for the existence of a value in the DTL.
It feels like there is a better solution altogether to suggest, but its not clear what the real world use case is here.
Sean.
go to post
Hi Francisco,
Have you tried using the RemoveItem() method on the Ens.Config.Production class?
go to post
There is nothing wrong with escaping a Solidus character. The JSON specification states that a Solidus "may" be escaped but does not have to be. You should find that most decoders will unescape the Solidus correctly, so you could just leave it as is.
go to post
There are a few ways to test the existence of a sub-string in a string...
Given...
and testing for "x"
within a tight loop with a million tests
$find is marginally quicker than the contains operator with a million operations in .004609 seconds, whilst the other two methods are relatively slower. I say relative because they are still quick in their own rights.
A wider question might not be which is the fastest, but how it's implemented with multiple tag tests. For instance a single variable creation is almost as expensive as the string test itself, and if you wrapped it all in a re-usable method, the method call would be 10x as expensive.
If you are dealing with two strings in the first instance, then a tight loop on $find is going to be your most optimum option. The other functions are probably just as performent in the right context, but if you have to dissect the strings to implement them, then the cost is not the test, but in the other operations that you have to do first.
go to post
Hi Scott,
A "Web Service" is just a generic term for an electronic service that operates over HTTP.
SOAP and REST can both be considered as a web service. Whilst SOAP is a protocol, REST is just an architectural style that operates over HTTP.
The NPI registry API can also be considered a web service, but it's clearly not SOAP, and it doesn't really conform to a REST architecture style either.
In fact if you look at the demo page you realise that the API is actually just a simple HTML form submit handler where the form values are sent in the GET request, as you can see here it submits all of the form values even if we provide just one form value...
You don't need to use a REST client library to work with this API, here is a simple command line demo just using the standard %Net library - I had to create an empty SSL/TLS configuration in the management portal named npiregistry as this needs to work over SSL.
For Ensemble you could just use the standard HTTP Outbound Adapter.
go to post
Hi Jack,
The important parts of the error message are
<UNDEFINED>
*k1
Which tells us that k1 is being used but has not been initialised.
Without the source code its a little hard to see how your are implementing this.
If this is your own code block then you could initialise k1 first
Set k1=""
Set k1=request.GetNextIndex("PIDgrpgrp("_(1)_").ORCgrp()",k1,.tSCTrans)
Alternatively, if you make k1 a context property then I believe it will initialise it for you.
Seems like a simple task to crack with a BPL sledgehammer. If there is no other BPL logic then you might want to consider just using a simple custom process, or via an HL7 routing rule with your own custom function
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_adv_custom_utilfunctions
go to post
Hi Fiona,
You shouldn't trust variables populated with embedded SQL.
You need to check the SQLCODE value to make sure you have actually found data, if SQLCODE=0 trust the data, if SQLCODE=100 the query didn't find any data, any other value should probably throw an error as there will be a problem with the query.
More here...
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RERR_sql_noerr
go to post
Hi Rui,
This JSON feature is only available from 2016.1 onward.
Take a look at this post for an alternative way to output JSON
https://community.intersystems.com/post/zenauxiliaryjsonprovider-object-json-serialization
go to post
Hi Eric,
Assuming you don't have escaped characters in the first or second field, you can just paste the following three lines into the terminal.
do file.LinkToFile("c:\Temp\file.csv")
for quit:file.AtEnd set ^People("Customers", "Acc.division",$zstrip($piece(file.ReadLine(),",",2),"<>W"))=""
You will end up with a global that looks like this...
^People("Customers","Acc.division",1235)=""
^People("Customers","Acc.division",3214)=""
If you have more complex / escaped data then here is an example of a CSV reader that will safely traverse the data (look at the Test examples)
https://gist.github.com/SeanConnelly/cb4ff970c2df5266d24c8802d56f48da
go to post
One approach would be to search the raw content.
Criterion Type = Body Property
Class = EnsLib.HL7.Message
Condition, IF [RawContent] [Contains] [OBX|]
Or you could search on a field that is always present in that segment
Criterion Type = VDoc Segment Field
Class = EnsLib.HL7.Message
Condition, IF [2.3:OBX] [SetIDOBX)] [!=] []