Hello Guys,

I search for éléments about queueing in WM brokers.

A client application send a notification to the WM service (exposed a a webservice) for polling éléments from the queue on the broker.
The WM service activates the trigger which subscribe to the document type to transmite to the client application.
The WM retrieves all documents and concatenate them in one response for the client (synchronous response).

Do you think that this solution is a good response ?
Is there API’s in WM to manipulate documents on a defined queue (to extract documents, to empty the queue) ?
If the response can not be received by the client, is there a risk that the service empty the queue (=> lose of documents) ?

Thanx inadvance for your ideas.
Best regards

Christophe

Christophe,

Is an application already publishing documents to the WM broker?

The design is using Broker as a simplistic database. Why not write the documents to a real database upon receipt and then just have your web service retrieve the data from the db?

Mark

Mark,

Thank you for your suggestion. But documents are already published on the broker by others interfaces.
And I’ve no choice on the design.

I think that I must use Broker APIs to retrieve documents. But I wonder what configuration I must specified for the trigger that declare the client to the queue.
The service which must poll the queue must be declare in the parameter of the trigger ? This trigger must be permanently disabled ?
=> As the service is launch by the client application and not by the trigger, I wonder if this trigger must be enabled.

Christophe

You don’t have to wait until receiving the request from your web service to retrieve the docs. I would store them to a database table as they arrive and then just retrieve (and merge) them when the web service request is received.

An IS trigger is a broker client. Just create the trigger normally, subscribing to the document and triggering a Flow to store them in the database table for retrieval when the web service client requests them.

You do not need to write directly to the Broker APIs for this scenario. I also would not add complexity by enabling and disabling the trigger.

Mark

Hello Mark,

Your idea is fantastic but it’s not the same than my client architect.
But I will submit that idea to him…

I wonder if it’s possible to use WM Repository in place of a database ? Perhaps there is a limit on the size of data to store ?

Waiting my architect response, I would like continue to exchange with you on the first idea.

What is the difference between Broker Admin and Broker Client APIs ?
Are they complementary ?
Is there a risk on the debugging of a such code ? (I’ve read somewhere else that these APIs are not always safe)

What is the complexity on “enabling and disabling the trigger” ? Is it neccesary to enable the trigger when the service call the code for retrieving documents on the queue ?

I know there’s a lot of questions on the same entry and I hope on your answer.

Thanx in advance

Christophe

Christophe,

I would not recommend use of WM Repository instead of a real database. It seems that you want to store messages (documents) until a web service request is received to retrieve them. The component that is used to store data is typically a database. Why not use one? Why all the effort to avoid using one?

Broker Admin APIs can also be used to retrieve documents, but have additional functions that can be used to create, delete subscriptions, inspect the number of clients subscribing to a Broker event (message), etc. An IS trigger is a broker client and subscribes to the documents according to the subscription details that you configure at design time. I fail to see the need to write code to retrieve mesages and invoke an IS service. That is exactly what an IS trigger does. Don’t reinvent the wheel.

In your first post you wrote:

Unless suspended due to some system maintenance, a trigger (which is just a subscriber) should not need to be “activated” or “enabled” or otherwise told to do anything. When you create a trigger you tell it what messages to listen for and what service(s) to call when one arrives.

A good resource to study so that you can properly advise your client is the “Publish Subscribe Developer’s Guide”. This can be found in PDF form in Developer/doc/guides or _documentation/Developer/Guides depending on your release. I’d also recommend that you build some simple prototypes so that you can better understand the options.

Mark

Mark,

I totally agree with you about your advice.

I wish to clarify the need.
“It seems that you want to store messages (documents) until a web service request is received to retrieve them. The component that is used to store data is typically a database.”
Yes. I need to store messages in a queue to avoid database (wish of my client)

Documents are published by other ressources at any time. On each notification (period according to a parameter), the exposed service trigger the retrieve of the messages and merge them into one message to the client application. The notification and response must be synchronous.

I know it is not the typical use of trigger and services, but I think that I’ve not the choice…

The question is simple : is that impossible to do ?
If it is possible, what are the difficulties that I could have ?

I hope that you can help me to resolve my dilemna.

Thank you.

Christophe

You can’t “trigger the retrieve” of the messages. The IS trigger that subscribes to the messages will have already invoked the associated Flow service each time a message is received.

Can it be done? Probably. Should it be done. No, not in my opinion.

To do so, you’ll need to write one or more Java services to use the Broker Admin API to determine if there are any messages in the Broker that match the subscription and then retrieve and process them.

I’m not going to argue with your client’s design. It’s overly complex and will be expensive to maintain and hard to support. Feel free to proceed, but I’m not willing to provide further assistance to implement this. Study the PDF I referenced earlier and the Broker Admin Java Docs. Be sure to double or triple any estimates to give yourself adequate learning time. I think you’re going to need it.

Mark

Mark,

Thank you for your patience and your teaching skills.

It’s now my job to persuade my client.

Best regards.

Christophe