What are all the types of EventDocument Retrieval in Broker

Hi Fellas,

This is a totally a newbie question.

Can some one elaborate on the various methods of document/event retrieval in WME.

Some of them I think of are as follows.

  1. Queue
  2. Event Type
  3. No Order

Are there any other methods. If so, what are the pros and cons of each of them.

Thanks a lot for your help.


Retrieval? I know you are a newbie ('cuz you told me), but do you mean subscription?

If so, I will try to rephrase your question – please pardon me being presumptuous:

How do I subscribe to data from the Enterprise Broker?

Please correct me if I am wrong, Learner.

You are Absolutely right…

Is there any one to help me out?

How do I subscribe to data from the Enterprise Broker? "

Thanks a lot


It depends entirely on what you are doing.

If you’re using off-the-shelf adapters, you don’t need to do anything explicit to establish subscriptions. The adapter will do that once you configure it for an event type.

If you’re using one of the APIs (C, Java, etc.) you can look at the subscription examples in the API docs.

This topic is fairly broad and can’t reasonably be covered meaningfully in a discussion forum. Have you run through the samples? The tutorial?

Of course you could always bring in a consultant, such as myself, to help jumpstart your efforts and provide knowledge transfer. :slight_smile:

Learner, this question can be answered in nine or ten different ways. Rob is right – for a complete answer of how Enterprise Broker works, your best bet is to talk to your local webMethods sales representative. Of course, if you are not a customer or a partner, this channel will be closed to you.

Alternatively, you can hire/contract somebody who can spend quality time with you explaining the ins-and-outs of Enterprise Broker and help you take your first steps towards a deployed solution. You can also try to read up on this forum and in the webMethods Advantage forums for more info on Enterprise Broker and webMethods in general.


I can enumerate if that is what you want. Rereading your fiirst post, I believe that is what you want.

Assum there is a producer P (of documents/events) and a consumer C (of documents/events). They can interact in four general modes:

  1. Deliver - P says to deliver a doc explicitly to C

  2. Publish/Subscribe - P says to publish a doc; C subscribes
    a) can subscribe by doc type
    b) can filter by predicate on doc content

  3. Request/Reply - P says to publish a doc; C subscribes; C delivers a reply doc to P

  4. Conversation - P and C deliver documents back and forth

The broker handles the delivery and publish, as well as the subscribe and filter. The interface for programs (adapters, agents, tools, et.al.) is a broker client, which can offer queues (for incoming docs) and subscriptions (to define what comes in the queues). Can create many incoming queues. Sending docs (deliver, publish) essentially goes into one broker queue, which it processes to figure out where the docs go.

There are many nuances to receiving docs in a queue. A series of docs can contain a sequence number - the order is maintained, and the receiver can tell when the last doc is received. Docs can be tagged and thus a reply containing a tag copied from the request doc allows the requestor to match replies with requests — handy when sending out many requests.

A receiver can get a doc but not have it leave the queue until another operation, an acknowledge. There is an API call that publishes one or more docs, and does the ack of the input doc … allowing agents (esp. ATC) to use the queue as a restart buffer … until the resulting docs are gone the original incoming doc is still queued.

A receiver can get docs out of order, by type, and by subscription. These nuances tend to be hidden under the hood of the adapters and tools.

All of this and more is in the documentation. If this is not the answer then I suspect you need to read more documentation to frame the question, or get with someone who knows for an hour on a white board.

Mark Thomsen
Alodar Systems, Inc.