Cannot use message type STRING in MQSeries receive port.

Home Page Forums BizTalk 2004 – BizTalk 2010 Cannot use message type STRING in MQSeries receive port.

Viewing 1 reply thread
  • Author
    Posts
    • #15472

      I wanted to start a new thread on this since it did not fall in line with the subject of my previous post.

      Basically, I am able to setup a receive port to an MQ Series port via MQSeries Adapter and receive/send messages as XMLDocument’s fine.

      However, I am receiving fixed width messages from our legacy systems and XLANG/s blows up when non-xml formatted message comes across.

      Sounds easy right? Simply change your message type to System.String instead of Xml.XmlDocument and be happy, right?. Wrong! It does not work.

      When I do this, I get the following exception:

      \”The Messaging engine failed to process a message submitted by adapter:MQSeries Source URL:MQS://cbtnt283/CBTNT283/QL.CBTNT.CNR.MACROCELL. Details:The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.\”

      I have been researching this all day and the closest similarity I found was the need to create a RawString from an XMLDocument coming in.

      Here is the linky: http://www.traceofthought.net/CommentView,guid,c5418f3d-2ea7-4530-ab9c-ae4c49154fcb.aspx

      I could not get this to work.

      Has anyone else experienced this?

      I find it hard to believe that out of the box, you can’t receive a non-xml message from MQSeries into your Orchestration. All this Legacy data is pre-xml and will not be changed for me.

      • #15473

        Thanks Greg.

        Here is exactly what I am trying to do. I am brand new to BizTalk and am sure I am spinning my wheels over something that is probably straight-forward.

        I want to do the following:
        1. Receive flatfile messages from MQSeries message queue.
        * These message come in 6 different formats. Therefore, I am taking in the whole message and letting a webmethod figure everything out for me.

        2. In an orchestration, I have a parallel operation which will a. Simply pass the existing message in the SAME format onto another MQSeries Queue. AND b. Call a WEBMETHOD with this message to be processed.

        That is it. I started exploring the flat file disassembler, which I believe is going to work. I just don’t think I am setting it up properly.

        Here is where I am at with that.

        1. I created a new schema for the flat file message which looks like this:

        <?xml version=\”1.0\” encoding=\”utf-16\” ?>
        – <xs:schema xmlns:b=\”http://schemas.microsoft.com/BizTalk/2003\” xmlns=\”http://EAICNR.schMacrocell\” targetNamespace=\”http://EAICNR.schMacrocell\” xmlns:xs=\”http://www.w3.org/2001/XMLSchema\”>
        – <xs:annotation>
        – <xs:appinfo>
        <schemaEditorExtension:schemaInfo namespaceAlias=\”b\” extensionClass=\”Microsoft.BizTalk.FlatFileExtension.FlatFileExtension\” standardName=\”Flat File\” xmlns:schemaEditorExtension=\”http://schemas.microsoft.com/BizTalk/2003/SchemaEditorExtensions\” />
        <b:schemaInfo standard=\”Flat File\” codepage=\”65001\” default_pad_char=\”\” pad_char_type=\”char\” count_positions_by_byte=\”false\” parser_optimization=\”speed\” lookahead_depth=\”3\” suppress_empty_nodes=\”false\” generate_empty_nodes=\”true\” allow_early_termination=\”false\” early_terminate_optional_fields=\”false\” allow_message_breakup_of_infix_root=\”false\” compile_parse_tables=\”false\” root_reference=\”Root\” />
        </xs:appinfo>
        </xs:annotation>
        – <xs:element name=\”Root\”>
        – <xs:annotation>
        – <xs:appinfo>
        <b:recordInfo structure=\”delimited\” child_delimiter_type=\”hex\” child_delimiter=\”0xD 0xA\” child_order=\”infix\” sequence_number=\”1\” preserve_delimiter_for_empty_data=\”true\” suppress_trailing_delimiters=\”false\” />
        </xs:appinfo>
        </xs:annotation>
        – <xs:complexType>
        – <xs:sequence>
        – <xs:annotation>
        – <xs:appinfo>
        <groupInfo sequence_number=\”0\” xmlns=\”http://schemas.microsoft.com/BizTalk/2003\” />
        </xs:appinfo>
        </xs:annotation>
        – <xs:element name=\”Root_Child1\” type=\”xs:string\”>
        – <xs:annotation>
        – <xs:appinfo>
        <b:fieldInfo justification=\”left\” sequence_number=\”1\” />
        </xs:appinfo>
        </xs:annotation>
        </xs:element>
        </xs:sequence>
        </xs:complexType>
        </xs:element>
        </xs:schema>

        2. Added a Flat file disassembler pipeline with the schema from step 1 in the Document schema property in the disassemble block.

        3. Changed the message type in the MQSeries receive port to the schema from step 1.

        4. Have a receive message set to a Message I created with message type of the schema from step 1. and with Operation to the Receive port.

        5. Then the parallel operations which simply call a webmethod and another which Sends the message to a MQSeries send port.

        All of this works perfectly if I was only dealing with XMLDocument and the message I put on the receive queue is an xml message. (example: <Request><Node>Test</Node></Request> )

        In reality, I am dealing with something which looks more like ( 1234567 CustomerName Address City State Zip)

        • #15474

          Got it.

          I needed to select my new pipeline in the receive location of my receive port…

    • #15471

      See my other post about the MessageType property na d receiving untyped messages into an orchestration

      Can you explain what you wish to do with the message in the orchestration

      Have you considered using the Flat File Disassembler to convert the string into an Xml document.

Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.