Clovertech

Error handling in Xlate Rule

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Error handling in Xlate Rule

  • Creator
    Topic
  • June 12, 2017 at 3:25 pm #55420
    Paul Glezen
    Participant

      I have a Xlate rule that invokes a Code Fragment UPOC.  The COPY action body calls a Tcl proc that inspects a few fields to determine whether translation should continue or whether the message should be written to the error DB.  I’m trying to determine the best way suspend processing and send the message to the error DB in the latter case.

      Unlike the TPS case, I don’t easily have control over the message disposition list.  I could set the Error behavior of the action to “Error” and then somehow cause an error in the Tcl proc.  But now I’m thinking a refactoring is in order whereby I invoke the Tcl proc as a Route Detail Pre-Processor.  Pre-TPS would be too early since this error determination is specific to the route detail.  I could then set the message disposition to ERROR if the message wasn’t appropriately populated for the route detail.

      The drawback is that I wouldn’t have the message parsed by the FRL at this stage.  Instead, I would have to count field positions on the message content and extract these myself.  Shouldn’t be a big problem; but it would hardcode field offsets in Tcl code that would probably be overlooked if the FRL ever changed.

      Is there a standard practice for this kind of thing?

    • Creator
      Topic
    Viewing 3 reply threads
    • Author
      Replies
      • June 12, 2017 at 4:32 pm #85260
        Jim Kosloskey
        Participant

          If you execute xpmerror in your Xlate code and then have the Action set to Error instead of the default skip that should cause the message to end up in the Error DB I think.

          Providing text related to the reason for the error (which if I recall ends up in the Metadata somewhere or at least in the Error DB) is helpful when troubleshooting from thee Error DB.

          email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

        • June 12, 2017 at 9:23 pm #85261
          Robert Milfajt
          Participant

            Jim, if they do that, won’t that stop that message from going to all downstream systems?  At least with standard interface set up without configuring not to “Remove all messages when any route detail fails”.

            Thanks,

            Bob

            Robert Milfajt
            Northwestern Medicine
            Chicago, IL

          • June 12, 2017 at 10:31 pm #85262
            Jim Kosloskey
            Participant

              Yes it will but I think that is what Paul indicated he wanted to occur.

              Paul if you want the error to only affect certain downstream threads then other steps would need to be taken and we could brainstorm.

              email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

            • June 12, 2017 at 11:03 pm #85263
              Paul Glezen
              Participant

                Thanks, Jim and Rob for chiming in.  Based on Jim’s initial response, I searched the docs for “xpmerror” and found it contained an option for how I wanted the Xlate engine to handle the error.  In my case, I chose “curdetail” for this option.  The docs claim it will send the copy of the message associated with the current route detail to the error DB while allowing the other route details to continue.  The other two options were “alldetail”, which fails all details (as Rob suspected it might); and “status” which subjected the error status to the setting in the Xlate action panel.

                I verified that my message was sent to the error DB when my Tcl proc invoked the xpmerror function.  I didn’t find my “reason string” in the metadata of the message that was sent to the error DB.  The API docs say the reason string is “attached to the record as its error context.”  I’m not sure how one accesses the “error context” of a message.

                But finding my “reason string” was a nice-to-have that I didn’t expect when I initially posted this inquiry.  Being able to send a message for a single route detail to the error DB without affecting other route details was what I was initially after.

                I’ll continue testing and update this thread if I observe behavior inconsistent with the docs.

            • Author
              Replies
            Viewing 3 reply threads
            • The forum ‘Cloverleaf’ is closed to new topics and replies.