Clovertech

Check for message size

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Check for message size

  • Creator
    Topic
  • November 13, 2009 at 2:26 pm #51335
    Gary Atkinson
    Participant

      Is there a way to check the message size before it leaves the engine?  I would like to check the message for X MB size and if it is greater than X to send the message to the error database.  I am received MDM messages and sometimes the message size is greater than the receiving system (Cerner) can handle.

    • Creator
      Topic
    Viewing 8 reply threads
    • Author
      Replies
      • November 13, 2009 at 5:33 pm #69765
        Jim Kosloskey
        Participant

          There are two ways I can think of.

          You will need a Tcl proc and I think this could be done either in a Tps proc or in an xltp proc (this one I am not sure of).

          You need to get the message from the message handle.

          Once you have that in a variable, you can either:

          Do a string bytelength

              or

          Do a string length

          The difference is that if UTF is in use the bytelength will give you the actual number of bytes (that might be important and would be different than what string length returns), string length on the other hand returns the number of characters no matter how many bytes of storage are actually consumed.

          So if a character in UTF takes 3 bytes and you have a single character message, bytelength would return 3 and length would return 1. Both would be correct but with different meanings.

          If it were me, given the scenario you posted, I would use bytelength.

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

        • November 13, 2009 at 5:37 pm #69766
          Gary Atkinson
          Participant

            Thanks Jim.

          • November 13, 2009 at 5:39 pm #69767
            Jim Kosloskey
            Participant

              Another option (I have done this before):

              Usually there is one field or one repeating segment that causes the excessive message size.

              Sometimes the receiving system can agree that if a certain size is exceeded, all of the data up to that limit (minus a length of an eye-catcher) be issued and a fixed literal be inserted so that the person on the receiving system can know they have an incomplete message.

              This is accomplished in the Xlate (with some reusable procs).

              That has worked well a couple of times for me in the past and may be worth persuing.

              If that looks like a possibility for you, let me know and I will be happy to share the procs and the techinque with you.

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

            • November 13, 2009 at 5:42 pm #69768
              Gary Atkinson
              Participant

                Sure Jim, just shoot me an email: gatkinson@bwmc.umms.org

              • November 13, 2009 at 6:57 pm #69769
                Gary Atkinson
                Participant

                  The below proc does not return anything when using hcitpstest.  Here is the code:

                  Code:


                  ######################################################################
                  # Name: check_msg_size
                  # Purpose:
                  # UPoC type: tps
                  # Args: tps keyedlist containing the following keys:
                  #       MODE    run mode (”start”, “run” or “time”)
                  #       MSGID   message handle
                  #       ARGS    user-supplied arguments:
                  #              
                  #
                  # Returns: tps disposition list:
                  #          
                  #

                  proc check_msg_size { args } {
                     keylget args MODE mode               ;# Fetch mode
                     set comment “MESSAGE IS TOO LARGE, NOTIFY VENDOR”
                     set dispList {} ;# Nothing to return

                     switch -exact — $mode {
                         start {
                             # Perform special init functions
                     # N.B.: there may or may not be a MSGID key in args
                         }

                         run {
                     # ‘run’ mode always has a MSGID; fetch and process it
                             keylget args MSGID mh
                             set msg [msgget $mh]
                             set msg_len [string bytelength $msg]
                             if { $msg_len > 4089446 } {
                                      msgmetaset $mh USERDATA $comment
                              lappend dispList “ERROR $mh”
                             } else {
                              lappend dispList “CONTINUE $mh”
                             }
                         }

                         time {
                             # Timer-based processing
                     # N.B.: there may or may not be a MSGID key in args
                         }
                         
                         shutdown {
                     # Doing some clean-up work
                  }
                     }

                     return $dispList
                  }

                • November 13, 2009 at 7:03 pm #69770
                  Gary Atkinson
                  Participant

                    I did run a very small message through and hcitpstest returned the disposition and the message.

                  • November 18, 2009 at 5:15 pm #69771
                    Sergey Sevastyanov
                    Participant

                      Gary,

                      To add to Jim’s 3rd option – we split long MDM messages that we send to one of our vendors into 2 or more messages using continuation pointer in MSH-14 and ADD and DSC segments. Of course the receiving system should be able to receive such messages.

                    • November 18, 2009 at 6:12 pm #69772
                      Jim Kosloskey
                      Participant

                        Sergei,

                        I did not mention that as an option because I have never found a vendor that could understand or support the continuation concept.

                        So you say you have a vendor that does – would you care to name the vendor and system so we can all be aware of a vendor/product that has some potential?

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

                      • November 18, 2009 at 8:09 pm #69773
                        Sergey Sevastyanov
                        Participant

                          Sure, Jim,

                          The vendor is Partners Healthcare (www.partners.org). We break long MDM messages with Radiology results and OP Notes and Discharge Summaries.

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