Clovertech

Create Reply via java

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Create Reply via java

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