Announcement

Collapse
No announcement yet.

cant put channelMap on preprocessor and use on response transformer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • cant put channelMap on preprocessor and use on response transformer

    Hello,
    It seems that putting a channelMap key on the preprocessor script and retrieving it on the response tranformer is not allowed. On the response transformer retrieving the channelMap var returns a string "[object OBJECT]" and it should return a JS Object.
    I know that you could think that I am just printing an object but NO the channelMap var truly contains a java.lang.String with the char sequence "[object OBJECT]". Very weird indeed...
    I can use the channelMap var anywhere else like in destination transformer with no problems except in the response transformer...

    I am not supposed to use channel map to pass variables from the preprocessor to a response transformer? How can the response transformer "magically" screw up my channelMap var?

    Using Mirth 3.0.3
    Last edited by hugosoares2; 10-27-2014, 04:03 AM.

  • #2
    Uh, nope, that works perfectly fine for me.

    Example - Put JS Object In Channel Map
    • Preprocessor Script:
      Code:
      $c('obj', {test:'123'});
      return message;
    • Destination Response Transformer:
      Code:
      logger.info('obj.test: ' + $('obj').test);


    Send a message through, and you'll see that the JavaScript object is still intact:

    Code:
    [2014-10-23 09:08:40,741]  INFO  (response:?): obj.test: 123
    However, the difference comes when your destination has queuing enabled, and the connector message gets pulled from the database rather than the in-memory object. That happens, for example, when the queue buffer max size gets reached, and subsequent queued messages get persisted to the database without being added to the in-memory buffer. Anything non-serializable (like a JavaScript object) will be converted to a string when persisted to the database. If you need the object later on in the same form, consider storing the JSON representation in the channel map instead. Then the preprocessor would be something like this:

    Code:
    var obj = {test:'123'};
    $c('obj', JSON.stringify(obj));
    return message;
    And the response transformer like this:

    Code:
    var obj = JSON.parse($('obj'));
    logger.info('obj.test: ' + obj.test);
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #3
      Hi,
      thank you, this makes perfect sense now, I can finally sleep in peace .
      I has "trusting" to much on the channelMap by thinking it was never going to change my values or types of values (since an integer or object can become a string when converted for db store as you mentioned).

      I would say that it should be clearly stated that the best practice for using channel map is only use it for strings for now or else you could suffer the consequences...

      JSON.stringify is not so straight forward to use in the case your json object contains properties that do not implement the toJson function (like java objects). Also I don't think the user (me) should have to worry about that when using the channelMap.

      Why did mirth decide to blindly convert to string for serialization when storing in the db? That approach does not guarantee that the object gets deserialized correctly back to the client like this type of process always implies. How about binary serialization/deserialization instead?

      Comment


      • #4
        Originally posted by hugosoares2 View Post
        Why did mirth decide to blindly convert to string for serialization when storing in the db? That approach does not guarantee that the object gets deserialized correctly back to the client like this type of process always implies. How about binary serialization/deserialization instead?
        Even with binary serialization, not all objects will support it. You simply cannot serialize a connected Socket object for example. It has stateful properties native to the OS and physical machine Mirth Connect is running on. Doesn't matter whether you do XML, binary, or whatever serialization you want, you're not going to be able to deserialize and use that Socket somewhere else (like a different physical machine, or even in a different JVM). Nor would it even make sense, because that's not how TCP connections work.

        And just to clarify, it's not "blind" conversion. We use XStream to build up an XML DOM containing all appropriate fields with all appropriate aliases/attributes/etc. As long as the object implements Serializable, then there's no problem. Only when that XStream serialization fails do we fall back to the toString() representation. At that point, since we have to commit the data to the database one way or another, the toString() better than nothing.

        I would argue that XML string serialization is better than binary serialization too. XStream is very flexible and uses annotations to allow custom aliases (XML node names), class-specific converters (to do special things when marshalling/unmarshalling certain objects), and a lot more. Plus when you view a map value in the message browser, an arbitrary array of bytes from binary serialization isn't going to be very helpful.
        Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

        Nicholas Rupley
        Work: 949-237-6069
        Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


        - How do I foo?
        - You just bar.

        Comment


        • #5
          Ok.
          That makes more sense now, thank you.

          Comment

          Working...
          X