Create Reply via java

This topic has 8 replies, 3 voices, and was last updated 9 years, 3 months ago by Levy Lazarre.

Creator

Topic
September 14, 2015 at 3:46 pm #54816
Gabriel Mendes
Participant
Dear Clovertech experts,

I am creating an UPOC Java procedure and I must generate a reply message to be sent to Cloverleaf, and be threated. The problem is that due to the lack of documentation I don’t know how to sinalyze how the message is of Reply type.

Here is a part of my code where I am generating the message:

Code: DispositionList dl = new DispositionList(); ReportAcknowledgement reportAcknowledgement = new ReportAcknowledgement(); reportAcknowledgement.setAckCode(”AT”); dl.add( DispositionList.CONTINUE,cloverEnv.makeMessage(SimpleXML.convertToXML(reportAcknowledgement)));

I am sending an ACK in XML as reply and I will handle inside cloverleaf with a XSD and translate into a HL7 ACK message to send to the system who’s waiting for an acknowledgement.

I probably have to sinalyze that the message is a reply type on makeMessage Method, but I don’t know how to do that.

Can somebody give me a hand?
Creator

Topic

Viewing 7 reply threads

Author

Replies
- September 17, 2015 at 2:33 pm #83101
  Levy Lazarre
  Participant
  Hello, Gabriel
  
  In order to indicate the message type, you need to use the overloaded form of the makeMessage() method, with the constants supplied by Infor:
  
  Code: dl.add( DispositionList.CONTINUE,cloverEnv.makeMessage(SimpleXML.convertToXML(reportAcknowledgement), Message.REPLY_TYPE, Message.PROTOCOL_CLASS, true));
  
  This is documented in the Java doc for makeMessage():
  
  Code: public Message makeMessage(java.lang.String content, java.lang.String mType, java.lang.String mClass, boolean recover) throws CloverleafExceptionRequest Cloverleaf to create a message with specified string as content. Metadata fields type, class, and use_recovery_db are set explicitly. Parameters: content – message content Unicode string – will be stored as UTF-8 mType – “reply” or “data” message – use Message.REPLY_TYPE or Message.DATA_TYPE mClass – “engine” or “protocol” message – use Message.ENGINE_CLASS or Message.PROTOCOL_CLASS recover – whether or not to enable Cloverelaf recovery for this message. Throws: CloverleafException
  
  I hope this helps.
- September 17, 2015 at 7:36 pm #83102
  Gabriel Mendes
  Participant
  Levy, thank you very much for your reply! I will configure this way then
- September 24, 2015 at 2:11 pm #83103
  Gabriel Mendes
  Participant
  Levy, good morning
  
  I am having troubles in which context should I generate this reply message.
  
  In this configuration I have two threads: One HL7 Server that receives HL7 messages and xlate them to XML and sends to a second UPOC thread.
  
  This second UPOC thread needs to perform database operations and generate a reply message to the first thread that will forward them to the HL7 Sender, as AA, AT or AE.
  
  But I can’t figure out in which context on the secont thread I will generate my ACK, sinalyze it as a reply message and send it to the forward reply queue.
  
  Can you please give me a hand?[/img]
- September 24, 2015 at 3:48 pm #83104
  Levy Lazarre
  Participant
  Gabriel,
  
  It seems to me that you are in “run” mode in the UPOC. So I believe that your context should be “pdupoc_read”.
- September 24, 2015 at 9:17 pm #83105
  Allerson Pereira
  Participant
  Hi Levy,
  
  I’m working to Gabriel into this project so let me explain the scenario. Basically our main issue at the moment is the error 104.
  
  Workflow
  
  1. RIS send an ORU into CCG
  
  2. CCG get this ORU into a thread TCPIP (RIS_ORU)
  
  3. Route into a translation to XML
  
  3. The XML is sent into a UPOC thread (WRITE_REPORT)
  
  3.1. into WRITE_REPORT we send the XML to our Java classes to write into a Oracle DB.
  
  3.2. the context used to process this XML is sms_ob_data
  
  3.3. Once processed we will receive 3 possible results from Java which are AA, AE or AT.
  
  3.4. still into sms_ob_data I create a new XML message of type REPLY and send into DispositionList as OVER.
  
  3.5. still into sms_ob_data I just KILL the original message.
  
  4. from our WRITE_REPORT I created a route reply back to RIS_ORU to translate our XML into an HL7 ACK.
  
  5. I expect to send back the HL7 ACK to our RIS system.
  
  Java code, this is how I handle XML into step 3.4
  
  Code: Message ackReply = cloverEnv.makeMessage(ackXML, Message.REPLY_TYPE, Message.PROTOCOL_CLASS, true); dl.add(DispositionList.OVER, ackReply); dl.add(DispositionList.KILL, msg);
  
  Generated XML message (pre and post SMS)
  
  Code: [pd :thrd:INFO/0:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Placing msg on IB pre-SMS queue. [pd :pdtd:INFO/3:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] IB pre-SMS message details [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msg: 0x0260A710 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgType : REPLY [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgClass : PROTOCOL [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgState : Unknown: 0 (0) [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgPriority : 5120 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRecoveryDbState: Log:new (2) [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgFlags : 0x1008002 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgMid : [0.0.195] [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcMid : midNULL [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcMidGroup : midNULL [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgHostId : 1659563043 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgOrigSrcThread : WRITE_REPORTS [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgOrigDestThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcThread : WRITE_REPORTS [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgDestThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgXlateThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSkipXlate : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSepChars : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgNumRetries : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgGroupId : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgDriverControl : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRecordFormat : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRoutes : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgUserData : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgStaticIsDirty : 1 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgVariableIsDirty: 1 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeStartIb : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeStartOb : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeCurQueStart: 0.000 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeTotalQue : 0.000 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeRecovery : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgEoConfig : 0x00000000 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgData (BO) : 0x0260A810 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] message : ‘12697197ATCould not connect to Database’ [msg :Msg :INFO/0:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Writing to recovery database [dbi :rlog:INFO/1:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Write msg to recovery db w/state IB pre-SMS
  
  Code: [pd :thrd:INFO/0:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Placing REPLY msg on IB post-SMS queue. [pd :pdtd:INFO/3:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] IB post-SMS message details [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msg: 0x0260A710 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgType : REPLY [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgClass : ENGINE [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgState : IB pre-SMS (1) [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgPriority : 5120 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRecoveryDbState: Log:update (3) [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgFlags : 0x1008002 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgMid : [0.0.195] [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcMid : midNULL [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcMidGroup : midNULL [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgHostId : 1659563043 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgOrigSrcThread : WRITE_REPORTS [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgOrigDestThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSrcThread : WRITE_REPORTS [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgDestThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgXlateThread : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSkipXlate : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgSepChars : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgNumRetries : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgGroupId : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgDriverControl : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRecordFormat : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgRoutes : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgUserData : [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgStaticIsDirty : 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgVariableIsDirty: 0 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeStartIb : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeStartOb : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeCurQueStart: 0.000 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeTotalQue : 0.031 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgTimeRecovery : 1443127898.478 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgEoConfig : 0x00000000 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] msgData (BO) : 0x0260A810 [pd :pdtd:INFO/3:WRITE_REPORTS:–/–/—- –:–:–] message : ‘12697197ATCould not connect to Database’ [msg :Msg :INFO/0:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Updating the recovery database [dbi :rlog:INFO/1:WRITE_REPORTS:09/24/2015 17:51:38] [0.0.195] Update msg in recovery db to state IB post-SMS
  
  Error 104 (5 last lines)
  
  Code: [xlt :xlat:INFO/0: REPORT_xlate:09/24/2015 17:51:38] [0.0.195] Route & xlate REPLY msg from thread ‘WRITE_REPORTS’ [xlt :rout:INFO/0: REPORT_xlate:09/24/2015 17:51:38] Loading REPLY route configuration for WRITE_REPORTS [xlt :rout:INFO/1: REPORT_xlate:09/24/2015 17:51:38] Loading TrxId ‘_HCI_static_route_’ REPLY route details from ‘ [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { DEST RIS_ORU } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { ELEVATEWARNINGFORPARSE 0 } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { POSTPROCS { [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { ARGS {} } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { PROCS {} } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] } } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { PREPROCS { [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { ARGS {} } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { PROCS {} } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] } } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { READONLY 0 } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { TYPE xlate } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] { XLATE reportAcknowledgement_XML-HL7.xlt } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] } [xlt :rout:INFO/1: REPORT_xlate:–/–/—- –:–:–] ‘ [diag:leak:DBUG/0: REPORT_xlate:09/24/2015 17:51:38] diag rc alloc 0x03028A50 [xlt :rout:DBUG/1: REPORT_xlate:09/24/2015 17:51:38] loading reply route for RIS_ORU as detail ‘ [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { DEST RIS_ORU } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { ELEVATEWARNINGFORPARSE 0 } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { POSTPROCS { [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { ARGS {} } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { PROCS {} } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] } } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { PREPROCS { [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { ARGS {} } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { PROCS {} } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] } } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { READONLY 0 } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { TYPE xlate } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] { XLATE reportAcknowledgement_XML-HL7.xlt } [xlt :rout:DBUG/1: REPORT_xlate:–/–/—- –:–:–] ‘ [diag:leak:DBUG/0: REPORT_xlate:09/24/2015 17:51:38] diag rd alloc 0x02E52288 [xlt :rout:DBUG/1: REPORT_xlate:09/24/2015 17:51:38] loading destination for route(RIS_ORU) … done’ [diag:leak:DBUG/0: REPORT_xlate:09/24/2015 17:51:38] diag rpa alloc 0x03028230 [diag:leak:DBUG/0: REPORT_xlate:09/24/2015 17:51:38] diag rpa alloc 0x03022510 [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] Route config … [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] type = 1 [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] dest = RIS_ORU [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] readonly = 0 [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] XLT = reportAcknowledgement_XML-HL7.xlt [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] preprocs procs = [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] preprocs args = [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] postprocs procs = [xlt :rout:INFO/2: REPORT_xlate:09/24/2015 17:51:38] postprocs args = [util:nd :DBUG/0: REPORT_xlate:09/24/2015 17:51:38] UTIL NamedDataMap adding data 0x030344D8 for WRITE_REPORTS [diag:leak:DBUG/0: REPORT_xlate:09/24/2015 17:51:38] diag nde alloc 0x030280D0 [xlt :rout:ERR /0: REPORT_xlate:09/24/2015 17:51:38] [0.0.195] Reply message has no destination [xlt :xlat:INFO/0: REPORT_xlate:09/24/2015 17:51:38] WRITE_REPORTS post-xlate: # msg = 0; try = 1; force = 0 [xlt :xlat:INFO/1: REPORT_xlate:09/24/2015 17:51:38] [0.0.195] Xlate error: edb state 104; edb context ‘xlate error’ [dbi :rlog:INFO/0: REPORT_xlate:09/24/2015 17:51:38] [0.0.195] Transitioning msg to error db w/state 104 [dbi :rlog:INFO/1: REPORT_xlate:09/24/2015 17:51:38] [0.0.195] Update msg in recovery db to state xlate pre
  
  Considerations
  
  I found some missing fields into my new message (msgOrigDestThread, msgDestThread) but don’t know how to set them, is there a way to do it in Java? Is it related to 104 error?
  
  Is the context sms_ob_data the right place to do it?
  
  It is very important to our protect to have a proper ACK handle so generate raws ACKs is not an option, unfortunately.
  
  Please just, feel free to suggest a new approach if ours is not a valid one and let me know if you need any extra info.
  
  TIA
  
  Allerson
- September 25, 2015 at 3:28 pm #83106
  Levy Lazarre
  Participant
  Hi Allerson,
  
  Since you are doing the work in TPS Outbound Data, the right context is indeed “sms_ob_data”.
  
  I have reviewed your NetConfig and your routing appears correct to me. I have done something similar in the past with a HTTP thread and it worked fine. So maybe setting the destination thread on the reply message will fix the Cloverleaf 104 error.
  
  In order to set the destination, you have to access the metadata of the new reply message as follows:
  
  Code: Message ackReply = cloverEnv.makeMessage(ackXML, Message.REPLY_TYPE, Message.PROTOCOL_CLASS, true); // Get the message metadata MessageMetadata mmd = ackReply.metadata; // Set the message destination mmd.set(”ORIGDESTCONN”, “RIS_ORU”); mmd.set(”DESTCONN”, “RIS_ORU”); // OVER the reply message back to TPS IB REPLY; KILL the original message dl.add(DispositionList.OVER, ackReply); dl.add(DispositionList.KILL, msg);
  
  Good luck. If this doesn’t work, I would consider using a different type of outbound thread than UPOC (FILE for example with /dev/null as input and output) since you don’t use any scheduling.
- September 25, 2015 at 8:25 pm #83107
  Allerson Pereira
  Participant
  Hi Levy,
  
  thank you very much for your time, I do really appreciated it.
  
  About those metadata I tried but found they are both read-only properties so cant change it.
  
  I also tried using file protocol and had the same error 104.
  
  In the end I tried a different approach and hope you can tell me if hava any side effect on the cloverleaf engine.
  
  Instead of create a REPLY_TYPE I just created a regular message and send it into DL by OVER. I also deleted my route reply and used a normal route message. By this way I could send back the ack.
  
  Look how is my Java now:
  
  Code: Message ackReply = cloverEnv.makeMessage(ackXML); dl.add(DispositionList.OVER, ackReply); dl.add(DispositionList.KILL, msg);
  
  Once again, thank you very much.
  
  BR
  
  Allerson
- September 26, 2015 at 12:42 am #83108
  Levy Lazarre
  Participant
  Hi Allerson,
  
  This is very intriguing for “DESTCONN” is definitely not a read-only property. If you search this forum, you will find many posts where people have reset the DESTCONN.
  
  You are now sending back the new message as a DATA message to the inbound thread. I wasn’t aware that this could work properly without side-effects. I have never seen it done that way, but always in “Route Replies”.
  
  So I would say:
  
  1. Check your error DB for possible errors.
  
  2. Make sure that the ACK is actually getting to the sending application.
Author

Replies

Viewing 7 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.