2 Replies Latest reply on Nov 28, 2003 3:09 PM by 16198

    Can the AQ Adapter send a JMS Message?

    397860
      I'm trying to use the AQ adapter to enqueue an XML message into a queue who's payload type is AQ$JMS_TEXT_MESSAGE so that it can be consumed by a Message Driven Bean in OC4J.

      Simply sending the XML reults in:

      "AQ Adapter: ** Error ** Can not enqueue messages to queue PLEDGE. ADT Payload defined for Queue PLEDGE does not match with OAI Message. Please check attribute "Pledge". In order for the AQ Adapter to enqueue OAI messages to the queue, the queue payload must match the ADT imported through iStudio."

      I tried importing the AQ%JMS_TEXT_MESSAGE but can't see any easy way to construct it.

      Is this even possible?

      -Doug

        • 1. Re: Can the AQ Adapter send a JMS Message?
          mbrouwer-Oracle
          Doug,

          the AQ$JMS_TEXT_MESSAGE is an object type. So you'll need to import that type as your application view.
          The problem with this JMS objecttype is how to populate it.
          When your text (XML) is more than 4000 characters in length, the TEXT_LOB attribute should get the text. If less, the TEXT_VC attribute should get the text. In any case, the TEXT_LEN should be set to the length of the XML.
          AFAIK, you can't currently do this with InterConnect directly.
          The most popular solution is to have InterConnect deliver this message to a simple non-JMS queue and have some PL/SQL or java code convert it to a proper JMS text message and put it in the JMS text queue.
          There are some features in the DBMS_AQ package to register a plsql procedure to be triggered when a message arrives (dbms_aq.register). That could be a procedure which converts the message for you.

          In ProcessConnect (coming soon) there is a dedicated JMS adapter available.

          HTH, Marc
          • 2. Re: Can the AQ Adapter send a JMS Message?
            16198
            Another solution is just to use the DB Adapter to accept a VARCHAR2/CLOB containing the message which is then enqueued onto a AQ$_JMS_TEXT_MESSAGE-based queue. This, I suppose, eliminates the need to place the message in some intermediate non-JMS queue.