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.

Hi Francisco,

Have you tried using the RemoveItem() method on the Ens.Config.Production class?

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.

There are a few ways to test the existence of a sub-string in a string...

$find(string,tag)

string[tag

$match(string,tagPatternMatcher)

$lf(list,tag)

Given...

set string="a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z"

and testing for "x"

within a tight loop with a million tests

$find  = .004609

[      = .004813

$match = .008951

$lf    = .023201

$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. 

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...

https://npiregistry.cms.hhs.gov/api/?number=&enumeration_type=&taxonomy_description=&first_name=&last_name=&organization_name=&address_purpose=&city=baltimore&state=&postal_code=&country_code=&limit=&skip=

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.

USER>set req=##class(%Net.HttpRequest).%New()                                    
USER>set req.SSLConfiguration="npiregistry"
USER>set sc=req.Get("https://npiregistry.cms.hhs.gov/api?city=baltimore&postal_code=212")
USER>set results={}.%FromJSON(req.HttpResponse.Data)
USER>write results.%Get("result_count")
10

For Ensemble you could just use the standard HTTP Outbound Adapter.

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.

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

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

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.

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...

^People("Customers","Acc.division",1234)=""
^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

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)] [!=] []