Accessing original message in chained xlate

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Accessing original message in chained xlate

  • Creator
    Topic
  • #55000
    Andrew Wold
    Participant

      I am attempting to use a chained xlate and in the second xlate I need to access extra data from the original message which was not translated in the first xlate.

    Viewing 6 reply threads
    • Author
      Replies
      • #83752
        Jim Kosloskey
        Participant

          Have you looked in the USERDATA?

          I really don’t know where it would be stored but that frequently is where data which needs to pass along with a messagee is stored.

          Another option is to either store the fields in question (if there are not to many) in the USERDATA yourself either pre Xlate or within the Xlate.

          If there are too many fields such that you need the whole mesage (or maybe you have no idea what would be needed) then you will need to do that pre-xlate currently.

          email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

        • #83753
          Russ Ross
          Participant

            One technique to see what the USERDATA metadata looks like before developing any extract logic is to put a hold on the outbound thread or leave it turned off and play a message thru the inbound thread, and while the message is queued up in the recovery DB do

            hcidbdump -r -L

            and you will be able to see what is stored in USERDATA metadata.

            Now you will know what you are starting with and if it will serve your purpose.

            this might even show you which metadata field the orginal message is being stored in, too.

            Russ Ross
            RussRoss318@gmail.com

          • #83754
            Andrew Wold
            Participant

              Thanks for that tip Russ, that will help me out in the future. Unfortunately I couldn’t find the data I was looking for in the meta data and I think I’ll need to follow a different route to get the data like Jim had mentioned.

            • #83755
              Russ Ross
              Participant

                hcidbdump -r -L

                will also show what is stored in the USERDATA metadata.

                I used that technique when developing a script to write stuff to the USERDATA metadata.

                I will wee if I can locate my older post illustrating that script in case it is something you can leverage.

                Russ Ross
                RussRoss318@gmail.com

              • #83756
                Russ Ross
                Participant

                  I found the post at this URL:

                  <a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1367&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1367

                  Russ Ross
                  RussRoss318@gmail.com

                • #83757
                  Andrew Wold
                  Participant

                    Thanks, yeah I ended up writing something similar but in java instead. I’ll put my code below since I don’t see much java in these forums.

                    Here is the setter. I return a new Vector() but I don’t actually need any return value.

                    Code:

                    public class SetKeyValuePair extends XLTStrings {
                       @Override
                       public Vector xlateStrings(CloverEnv cloverEnv, Xpm xpm, Vector vector) throws CloverleafException {
                           PropertyTree userData = xpm.metadata.getUserdata();

                           if(vector.size() == 2 ) {
                               userData.put((String)vector.elementAt(0), (String) vector.elementAt(1));
                               xpm.metadata.setUserdata(userData);
                           }

                           return new Vector();
                       }
                    }

                    This is the getter.

                    Code:

                    public class GetKeyValuePair extends XLTString {
                       @Override
                       public Object xlateString(CloverEnv cloverEnv, Xpm xpm, String inVal) throws CloverleafException {
                           PropertyTree userData = xpm.metadata.getUserdata();

                           return userData.getString(inVal);
                       }
                    }

                  • #83758
                    Russ Ross
                    Participant

                      We have only written our UPOCs in TCL so far.

                      Here is something I just learned to consider when deciding to use JAVA instead of TCL that might sneak up on you down the road.

                      Incident : 9358108  Summary:

                      Cloverleaf 6.0.0 on AIX 7.1 TL4 SP1 (system security patch to JAVA 5 needed, but want to make sure this will not adversely impact Cloverleaf)

                      Response from Infor:

                      Cloverleaf will not use the java installed on the box so will not care if it is updated.

                      As we discussed on phone earlier of course this assumes that the cloverleaf folders are first in your path statements.

                      Only gotcha development noted was if you are using java upocs you need to compile your custom code using the same JDK version as cloverleaf is using.

                      If your upocs are tcl based like most then that is not an issue.

                      Russ Ross
                      RussRoss318@gmail.com

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