I am working on building a replacement to MIRTH and it looks like we are sending out non-standard HL7 ORU_R01 messages. OBR.5 should be just a single field but looks like we are sending a bunch of other data in this section.
<OBR.5>
<OBR.5.1>XXXX</OBR.5.1>
<OBR.5.2>XXXX</OBR.5.2>
<OBR.5.3>XXXXX</OBR.5.3>
<OBR.5.5>XXXXX</OBR.5.5>
<OBR.5.6>XXXX</OBR.5.6>
<OBR.5.7/>
<OBR.5.8>XXXXXXXXXX</OBR.5.8>
<OBR.5.10>XXXXXXX</OBR.5.10>
<OBR.5.11>X</OBR.5.11>
<OBR.5.12>X</OBR.5.12>
<OBR.5.13>XXXXX</OBR.5.13>
<OBR.5.15>XXXXXXX</OBR.5.15>
</OBR.5>
It seems like I should be able to something like the following.
obr.getObr5_Priority().getExtraComponents().getComponent(2).setData(...)
But I am having issues trying to find the correct way to set the different segments. All the fields are Strings.
Found something that I think has ended up working for us.
ID expirationDate = new ID(obr.getMessage(), 502);
expirationDate.setValue(format2.format(date));
obr.getObr5_Priority().getExtraComponents().getComponent(0).setData(expirationDate);
Where 503 refers to which element you want to set. In this case I am trying to set OBR-5.2. getComponent(0) because it's the first extra component I am adding for this particular segment. I am not sure entirely if my explanation here is correct but it creates a message we need and parses as I'd expect so its my best guess.
Dereived the answer from this old email thread https://sourceforge.net/p/hl7api/mailman/hl7api-devel/thread/0C32A03544668145A925DD2C339F2BED017924D8%40FFX-INF-EX-V1.cgifederal.com/#msg19632481
Related
I am writing my first Wireshark dissector. I am writing it in Lua, using this as an example. My communication protocol embeds a command ID in the response header, followed by well-defined payloads that differ based on the command ID. So far, I've been structuring the ProtoFields such that the Abbreviated name of the field (the string used in filters) follows a naming convention like this
proto_name.command_name.field_name
Some commands have similar fields, like in the following example
myproto.cmd_update.updateId
myproto.cmd_update_ack.updateId
where, per the protocol, an update command must be acknowledged with a update_ack command with the same updateId payload. Ideally, i would like to create a wireshark filter such that I can see all packets pertaining to the updateId field. I tried creating a filter like
myproto.*.updateId == 0x1234
but that appears to be invalid wireshark filter syntax. I don't want to make the filter explicit like
myproto.cmd_update.updateId == 0x1234 or myproto.cmd_update_ack.updateId == 0x1234
because in my actual protocol there are many more commands with similar/related fields. Is there a filter syntax I can use? Or perhaps, should I structure my dissector's ProtoField abbreviations differently?
There doesn't appear to be a wildcard syntax for the filter line, so I wound up solving this in the dissector itself. In addition to the myproto.*.updateId fields, I also added another field called myproto.updateId (note the lack of the wildcard in the middle). Its value is set to the same thing as the full blown field name, which means that I now have just one field name to search against. I also set this field as hidden = true to hide it from view.
It's a bit of a hack, but gives me what I want.
You could try using a Wireshark display filter macro.
I am pretty new to Cumulocity and I am trying to get data into the platform from my own device using mqtt and the smartrest templates. I can get data in using the static templates but they only support certain data types. I am struggling to create the appropriate smartrest template in the UI and the documentation doesn't go into much detail.
I get that the template name goes in the MQTT topic (or selected on login as part of the username) in s/ut/template_name and the messageId of the messages in the template get matched to the first CSV field of the MQTT publish payload. What I don't get is the template terminology. In the UI I choose API->Measurement and Method->POST and I am presented with required values $.type and $.time. My questions:
Is $.type the "measurement fragment type" name or do I have to make it "c8y_CustomMeasurement"? Can I call it whatever I want?
$.time has a value field. Is this the default value if one is not supplied in the publish?
I assume I need to add a numerical value in the optional API values. To link it to the value of the data point should I make the key "c8y_CustomMeasurement.custom.value"?
Am I way off base here?
Every time I publish to my own smartrest template the server drops the connection so I assume its an error in my template setup but I don't see a way of accessing debug messages (also nothing is published back to me on s/e or s/dt).
For the sake of an example, lets say I wish to publish a unitless, timestamped pulse count with payload format "mId,ts,value" with example data "p01,'2017-07-17 12:34:00',1234"
What you wrote so far is mostly correct just to be a bit more precise:
The topic is s/uc/template_id (not the template name, this is just a label)
The $.type refers to the 'type' fragment in the measurement JSON. It is a free text field
In 99% of cases you want to leave the $.time empty. If you set something here it is not the default but fixed to that timestamp and you cannot change it when using the template. If you leave it empty and still not send something in
Example: p01,2017-07-17T12:34:00,1234 (no quotes arounf timestamp and ISO8601 format
Example without sending time: p01,,1234 (sending empty string as time results in server time beeing set. The template is the same)
Hope these points help you to find you issue
Given a RESTful API, implemented in Rails, I want to include in the responses not only the errors messages, generated by ActiveModel::Validations, but also custom error codes. First of all I would like to point out that I am not talking about HTTP Status codes. I am talking about having an error of any type (from general errors like record not found to small validation errors like username can't be blank) be mapped to a unique numeric code, that is custom application-specific error codes. Let me give an example - given a list of error codes, like:
1: record not found
... some other errors
# Validation errors for User model between 1000 to 2000
1001: first name can't be blank
1002: first name must contain at least 3 characters
1003: last name can't be blank
1004: last name must contain at least 3 characters
...some other errors
If I have a form for a user and submit it with empty fields for first and last name, I want to have in the response body something like:
{error_codes: [1001, 1002, 1003, 1004]}
or something similar (for example I could have an array of error objects, each with a code, message for developer, message for user etc.). Let me give an example with the Twilio API, taken from RESTful API Design: what about errors?:
Here, 20003 is some custom Twilio-specific code. The question is - how can this be implemented in Rails? I see several difficult aspects:
how do I get a list of all possible errors that can be encountered. It is hard to get such a list even only for the validation errors, let alone the other types of errors that can occur.
how should this list be organized - maybe in a YAML file?
how do I access the list - maybe something similar to the way translations are accessed via I18n.t?
I will really appreciate any advice on the topic. Thank you.
P.S. I think this is a similar question.
ActiveModel built-in validators can be found here. Sometimes one validator can check for more than one thing and output different messages. The easiest way to see them all is, as you've guessed, in its I18n yaml file, which can be found here.
One way of doing what you want is overwriting those messages with your custom codes. Another way is passing a custom message when explicitly attaching a validator to your models.
validates :name, message: 'code:001 - my custom message'
Those two options won't help you with structure, though. You won't have a different key code on your json out of the box.
One way you can accomplish that is to can create a helper to parse the error messages and extract the codes after they have been assigned to a model instance. Something along the lines of:
def extract_error_codes(error_messages)
error_messages.map{ |message| message.match('^code:(\d+)\s-')[1] }
end
That would give you an array of error codes for that instance if you'd used the format code:001 - my custom message.
Another, much more involved way, is to tap into ActiveModel's Validator class and store an error code when a validation fails. That would require going into each validator to assign the code.
I am using FIXT1.1 and FIX Application version 5.0SP2.
I added some custom fields to the QuotSetAckGrp, part of MassQuoteAcknowledgement message. However, when quickfix reads the repeating group, it does not read the custom fields as part of the repeating groups. Instead, it treats the custom fields are regular parent-level fields and throws a "Tag appears more than once" session level reject.
Appreciate any inputs to help resolve the issue.
You need to modify the receiver's AppDataDictionary to match the messages that your sender is sending. Also, you need to set UseDataDictionary=Y in your config.
QF/j needs to look at the DD xml file to know what fields are in a repeating group, else it cannot know where each group member ends.
When the engine encounters a field that isn't inside the DD's repeating group definition, it assumes that the current group member ended with the previous tag.
Here's a howto for customizing your DD:
http://quickfixn.org/tutorial/custom-fields-groups-and-messages
(The above link is for QF/n, but it's nearly the same for QF/j.)
See the QuickFIX/J User FAQ, topic "I altered my data dictionary. Should I regenerate/rebuild QF/J?".
OUTGOING MSGS: The DD xml file is irrelevant when you construct
outgoing messages. You can pretty much add whatever fields you want to
messages using the generic field setters (setString, setInt, etc) and
QF will let you. The only trouble is with repeating groups. QF will
write repeating group element ordering according to the DD that was
used for code generation. If you altered any groups that are part of
outgoing messages, you DEFINITELY need to rebuild.
To rebuild QuickFIX/J to accept your custom data dictionary, please refer to the answer I gave in the following StackOverflow post.
HTH.
I've read the documentation, but what I need to know is:
I'm not using a fictitious stock quote service (with an imaginary wsdl file). I'm using a different service with a different name.
Where, among the thousands and thousands of lines of code that have been generated, will I find the Scala trait(s) that I need to put together that correspond to this line in the documentation's example:
val service = (new stockquote.StockQuoteSoap12Bindings with scalaxb.SoapClients with scalaxb.DispatchHttpClients {}).service
Now, you might be thinking "Why not just search for Soap12Bindings in the generated code"? Good idea - but that turns up 0 results.
The example in the documentation is outdated, or too specific. (The documentation is also internally inconsistent and inconsistent with the actual filenames output with scalaxb.)
First, search for SoapBindings instead of Soap12Bindings to find the service-specific trait (the first trait).
Then, instead of scalaxb.SoapClients, use scalaxb.Soap11Clients.