What is webMethods Broker.?
In the webMethods system, Integration Servers exchange documents via publication and subscription. One Integration Server publishes a document and one or more Integration Servers subscribe to and process that document.
The Broker forms the globally scalable messaging backbone of webMethods components.
It provides the infrastructure for implementing asynchronous, message-based solutions that are built on the publish-and-subscribe model or one of its variants, request/reply or publish-and-wait. webMethods Broker serves as an intermediary that routes data from publishers to subscribers.
Information producers publish data to webMethods Broker and then move on to other activities, while information consumers subscribe to and retrieve the data when convenient.
Broker Architecture:
A webMethods Broker environment consists of two main components:
- Broker Server, the run-time component with which publishers and subscribers interact.
- Broker user interface, the administrative component that runs on My webMethods Server
The Broker Monitor is automatically installed when you install Broker Server, it monitors all of the Broker Servers running in the webMethods Broker environment. It will automatically attempt to restart any Broker Server that stops running in its environment.
Broker Server & Broker
Broker Server is the container within which one or more Brokers reside. A Broker Server performs the communication-related work of receiving client requests, dispatching requests to the requested resource (which in this case, is a Broker), and returning responses to clients. It also manages memory and disk resources for all the Brokers that reside on it.
Broker is an entity that resides on a Broker Server. When a client connects to Broker Server, the client specifies the Broker with which it wants to interact.
A Broker encompasses the following types of objects:
- Document types
- Client Groups
- Client State Objects
What is Document Type?Document Type name consists of two components: a folder path and a base document type name. folderName::subFolderName::documentTypeName
If the document type is created through Designer, the Broker document type name includes the preface "wm::is::" before the folderName::documentTypeName convention
Example: wm::is::Training::docs::testBrokerDoc
Document Type Properties - Each document type has properties associated with it that determine how the Broker handles instances of that document type at run time.
Time to live(TTL) specifies how long Broker maintains instances of this document type once they are published.
Validation indicates whether Broker validates instances of this document type and if so, if the document can contain fields that are not defined in the document type.
- Full. The document can contain fields declared in the document type only.
- Open. The document can contain fields that are not declared in the document type.
- None. Broker does not validate instances of this document type.
Storage type determines whether instances of this document type are stored in memory or on disk.
- Volatile documents are stored in local memory only.
- Guaranteed documents are persisted to disk so that they can be recovered in the event of a power failure or a server restart.
Client:
A client is an object on the Broker that represents the connection between a client program and the Broker. A client program creates a client to publish or retrieve documents.
For example, a customer-facing Web application might create a client to publish sales order documents. The back-end accounting system and the order fulfillment systems might create their own clients to subscribe to the sales order documents. Broker routes the documents published by the Web applications client to the clients for the accounting and order fulfillment systems.
What is Publish & Subscribe Model.?
The publish-and-subscribe model is a specific type of message-based solution in which applications exchange messages (called documents in webMethods) through a third entity called Broker.
In solutions based on this model, applications that produce information (publishers) send the information to the Broker entity and applications that require the information (subscribers) connect to the Broker and retrieve the information they need.
Most important services
- pub.publish:publish
- pub.publish:deliver
Publishing to Broker
Publishing when the Broker is down or not available
Other useful services, but in real-time usage is very less
- pub.publish:publishAndWait
- pub.publish:deliverAndWait
- pub.publish:reply
- pub.publish:waitForReply
How to connect Integration Server (IS) to Broker
Broker Monitor (Mon) should be up and running, then connect IS with Broker.
- Open the Integration Server Administrator.
- In the Settings menu of the Navigation panel, click Messaging.
- Under Broker Configuration, click Broker Settings.
- Click Edit Broker Settings.
If Broker is installed on Win, then start Broker Monitor from Windows> services
Note: You can configure IS with only one Broker, but one Broker can be connected with multiple IS.
Once you have updated the Broker details, then restart the IS.
Note: At the time of writing this blog, I am using wM IS 10.15 and Broker version 7.x (But it's deprecated). So IS UI may be different in lower or higher version.
Now, create a simple flow in designer to publish a document to Broker
Create a small document and change Publishable type as True and select provider alias as Broker_Local (which I have created in IS admin page)
Create a flow service and drag a publish build in service to publish a document to Broker.
Subscription Flow
Create a Native trigger to subscribe the document and invoke flow service for processing it.
Simple flow for processing the subscribed doc
Execute the publish flow service and see the result.
Source: https://documentation.softwareag.com
Thanks for reading :-)