First I'd suggest to change:
Set httpRequest.Server = "http://127.0.0.1:8080"
to:
Set httpRequest.Server = "127.0.0.1"
Set httpRequest.Port = "8080"
I would also check the status after:
Set status = httpRequest.Post("/collect_patient_information")
And then try again.
Excellent! Well done 👏
And last but not least, don't forget to cleanup.
Who/when ^SPOOL is cleaned?
What part should I clean? Just a shameless Kill ^SPOOL ?
IMHO, in addition to @Alexey Maslov notes, that's another (good) reason why device 2, the spool device, has been log forgotten (and buried) for good.
You mention you need to connect to Ensemble but your product version says IRIS. I assume you need to connect to IRIS.
In Windows you can install IRIS ODBC drivers and in Control Panel create a DSN to connect to a IRIS Namespace. Then in SSMS follow the instructions to connect to an external database using an ODBC DSN (I have no experience on this).
Make sure you use the correct 32 or 64 bits driver and DSN definitions (in Windows you can define 32 or 64 bits DSN), I'm not sure if Microsoft SQL Server Management Studio (SSMS) is 32 or 64 bits application, find that out first.
Another option is to use IRIS JDBC drivers, make sure you install the correct Java JRE for the JDBC drivers you are using.
Since this is windows, maybe ODBC is more convenient.
I'd suggest to start with the documentation pages:
Defining and Using XData Blocks
There you can find a lot of info to start with, then if you need additional info come back with more specific questions.
I would say no.
Lookup Tables are simple and ready to use, if you need more, it's relatively simple to implement a custom functionality with audit, lat modification time, user etc.
I don't think this information is stored in Lookup Tables.
Only table name, key and value are stored.
I'm not sure what "HL7 Reference Guide" exactly means for you, however, within "health enabled products" (IRIS for Health, Healthhare Connect, Healthshare UCR etc.) there are "HL7 Schemas" for all HL7 v2 variants up to 2.8.2.
Can be accessed from Management Portal Interoperability -> Interoperate -> HL7 v2.x -> HL7 v2.x Schema Structures.
There, for each version you can browse in detail the HL7 message structure, segments, field, subfields etc down to code tables associated to coded entries/fields.
If you don't have IRIS for Health, you can download IRIS for Health community edition that is free for non commercial/production use (check license for details).
Well Julius, in general I would agree with you under that circumstances, BUT, in this particular case, the code he has implemented correspond exactly to the "Defining a Computed Property" documentation sample.
This is not a case of using %Library.PropertyHelper in random code, it's a case of using it according to documentation.
Granted that he is trying to use a variable instead of a string constant and (for good reasons IMO) does not work due of implementation constraints.
I agree that understanding the actual requirements and what needs to be implemented (the real problem), a viable solution can be suggested.
This is interesting.
It is evident that when the class is compiled IRIS parse the <PropertyName>Computation() method(s) to find out what properties are actually used/referenced/passed to the cols.getfield() method(s), then it use this information to set the "fields" multidimensional property of %Library.PropertyHelper class before calling the <PropertyName>Computation() method.
This way only the used properties are set in the "fields" multidimensional property of %Library.PropertyHelper class.
This optimization improves performance in case of a class with many properties, possibly "complex" properties (calculated, references etc.) and I believe this is why has been implemented.
The "parser" is...simple, very simple.
To prove this assumption I wrote a little sample:
Class Community.Computation Extends %Persistent
{
Property FirstName As %String;
Property LastName As %String;
Property FullName As %String [ SqlComputed ];
ClassMethod FullNameComputation(cols As %Library.PropertyHelper) As %String
{
; cols.getfield("FirstName")
; cols.getfield("LastName")
return ..FullNameComputationSub(cols,"FirstName","LastName")
}
ClassMethod FullNameComputationSub(cols As %Library.PropertyHelper, p1 As %String, p2 As %String) As %String
{
return cols.getfield(p1)_" "_cols.getfield(p2)
}
/// do ##class(Community.Computation).test()
ClassMethod test()
{
set obj=..%New()
set obj.FirstName="Enrico"
set obj.LastName="Parisi"
write obj.FullName,!
}
}
If I run test() I get:
do ##class(Community.Computation).test()
Enrico ParisiIf I remove the commented line "; cols.getfield("FirstName")" and run test() again:
do ##class(Community.Computation).test()
ParisiIf you look at your error:
"set cols.fields("ropert")={ropert}'"
That's the parser that found "cols.getfield(property)" and assuming a string was passed removed the first and last characters (assuming were double quotes), so it got "ropert".
Bottom line, cols.fields() can only be used passing a string constant with a property name.
Thinking of this, in fact I really believe it's not possible to implement setter/getter methods in datatype classes because datatype methods are, by design, classmethods and getter/setter methods are and must be instance methods.
If you using IRIS prebuilt HL7 Business Service components, like EnsLib.HL7.Service.TCPService, it is not possible.
There is no place where you can call Transform() method.
If you have implemented your own BS, then you have full control.
Having said that, I ask again, what's the problem of implementing a simple HL7 Routing Business Process with a simple rule and transformation between BS and BO??
It can be done in few mouse clicks...
Within setter and getter method you need to use Instance Variable to set/get the actual property value:
Property NewProperty1 As %String;
Method NewProperty1Get() As %String [ ServerOnly = 1 ]
{
Quit i%NewProperty1
}
Method NewProperty1Set(Arg As %String) As %Status [ ServerOnly = 1 ]
{
Set i%NewProperty1=123
Quit $$$OK
}
To implement it in datatype class try using a method generator.
Maybe if you explain what you are trying to achieve there can be a different solution.
dataEntry is source message
dataTransform is target/transformed message
What kind of Business Service are you using?
I'm having difficulties understanding your question.
Can you please post your full property definition containing SqlComputeCode?
Can you please explain what object/class is cols? I don't know any class that implement the method getfield()
Using IRIS prebuilt HL7 Business Service components it is not possible.
What's the problem of implementing a simple HL7 Routing Business Process with a simple rule and transformation between BS and BO??
It can be done in few mouse clicks...
I don't think you can implement/override getter and setter in datatype definition.
Depending on your actual needs, you can implement LogicalToStorage and StorageToLogical.
Please note that implementing getter and setter (PropertyGet() and PropertySet()) has no effect in SQL projection.
My guess (I may be wrong!) is that you did not configure IIS existingResponse PassThrough option.
In IIS, if you don't configure that options, application errors (like IRIS REST errors) are not sent back to the client, instead a "standard IIS error" (my definition) is sent back to the client (i.e. browser).
Check this IRIS documentation on Configuring IIS to Return SOAP Fault Details, although it refers to soap, the same apply to REST.
You may want to google "IIS existingResponse PassThrough" for more info.
Again, I may be wrong...but I bet on this being the issue here.
Ops! You are right! 😊
In my defense...it was late 😂
Translation:
Hello, good afternoon, I hope you are well.
Have you received an answer to this query? Have you been able to resolve it in any way? I'm dealing with this same thing now and I still can't figure it out.
If you have any help, I would greatly appreciate it.
$Piece("SAD,MED,TEN,BOB,RAN",",",$r(4)+1)
Ciao Alessandro,
your words embarrass me! ☺
If you change:
w x
With:
Do $system.OBJ.DisplayError(tSC)
What do you get in the terminal?
Can you please explain in detail what you mean with "I pull it out".
From where?
Using objects?
Using SQL?
If SQL, from what language you run the query? What mode?
Nice write up, I agree to most of your comments.
Nowadays I personally try to avoid $Select() and $Case() because I realized that it's often difficult to read, particularly for new comers.
I fully agree on using full command keywords, in my case including for most common ones although I admit that sometime I almost automatically type a single letter Quit with postcondition to exit a loop (Q:key="")! 😁
As for "Use all lowercase for command keywords"..well, this is really a matter of taste, I like commands with capital first letter, I find it increase readability, but, again, it a subjective opinion.
One thing for sure, whatever you choose, stick with it! Be consistent.
In fact when I happen to modify existing code, I try to adapt new code to the existing style (if any 😱 ).
About using full function names for intrinsic functions....well, I agree but meanwhile I have to admit I'm not THAT consistent, I sometime use abbreviated/single letter for some functions like $d, $zdth, $i. Maybe I need to improve on this. 😊
I have mixed feelings about the (relatively) new Return command.
While I understand the usefulness in some circumstances (i.e. error processing) I really (really, really) don't like its usage "in the middle of code".
To me good code should have one, and only one, "exit point" at the end, I consider trowing Return commands here and there in the middle of code (like a method) the same of using a Goto.
That's why I still don't use it that much even now, last line is the only exit point and I use Quit, changing it to Return makes very little difference.
Hi
I found the rules here.
I understand that at the moment only some of the rules are applied to Open Exchange projects, but as you said, some customer may use the other rules to measure code quality or maybe simply to learn how to write good quality code.
Having published "wrong rules", whatever is the use, I don't think is a good thing. Fix the rule or remove it, before someone think they are good practice or useful info.
The point was that the "Compliant Solution" is actually invalid code/definition.
I fully agree that quoted property declarations should be avoided.
Some more notes about ObjectScriptQuality rules.
Rule: SQL Delimited Identifiers with double quotes
Both the "Non-compliant Code Example" and "Compliant Solution" for the Class Query sample contain an invalid SQL statement.
For example the Compliant Solution for the Class Query sample is:
Query Example() As %SQLQuery(CONTAINID = 1, ROWSPEC = "ID,Corporation:%Integer,IDNumber:%Integer,Name:%String, DisplayName:%String")
{
SELECT ID, Corporation->CorporationID, IDNumber, Name, (IDNumber || ' - ' || Name) As
FROM General.Contacts
ORDER BY Name
}
At the end of the first line of the select statement the column alias is missing after "As ...".
In othe samples, I think it's misleading the naming of "SomeCondition" where in fact it represents a value:
&SQL(SELECT Val1, Val2
INTO :val1, :val2
FROM Table
WHERE Val1='SomeCondition')
Here 'SomeCondition' is not a condition, it's a value, I'd rather use/name it 'SomeValue'.
I refrain from commenting that in the sample SQL above, the query returns a constant as first column/value (Val1).....
Rule: Use of &sql
The rule states:
The problem with using &sql(...) is that the execution plan will be calculated the first time the query is executed, and never be re-evaluated again.2
This was true, however since 2020.1 IRIS uses "Universal Query Cache" for both embedded SQL and Dynamic Queries.
If &sql() should be avoided (and this can be discussed...), a better, strong, valid, true reason should be provided.
Rule: Use of OPEN is discouraged
The OPEN command has a very complicated syntax which is difficult to get right.
It is preferable to use classes from the %IO package instead which are much easier to use and provide the same functionality.
The proposed solution breaks rule Undocumented class/method
The %IO package is never mentioned in the documentation and is (by default) hidden in class reference.
Depending on the device, different documented classes can be used instead of %IO package.
Maybe we can discuss/ask InterSystems what are the plans for %IO package.
Is it here to stay? Is it going to be deprecated? Is it going to be documented?
More importantly, can we safely use it? Sometime (often?) undocumented means that should not be used by "user code" and/or it can be changed (by ISC) without notice in any future version.
I had a look to the various rules, including non BUGS, and in some case I don't fully agree to the rule, but I understand sometimes it's a matter of opinion.
There are however cases where the rule are simply wrong, other cases where the supplied sample is wrong.
I haven't checked all the rules (yet? 😊), the errors I found so far are:
Rule Property name declared with quotes
It's funny that the "Compliant Solution" is simply an invalid/wrong property definition! 😱
Property Hello_World;While I fully agree to avoid quoted property declarations and the use of "non standard" property names (like "Hello_World") I can imagine some scenario where this is definitely required and cannot be avoided.
Rule Incompatible argument type in a method
According to the description, running the provided sample code, in two cases, call to DoWork2() and DoWork3() methods, raise a "PARAMETER error" message on runtime.
In fact, the supplied code never raise any error.
Has anyone ever checked/reviewed the rules and found dubious rules or don't fully agree with some rule?
Please note that jsonob.value.labReports is an array, I assume that it possibly can contains multiple pdfs, so an iterator is required.