Step 8: Synchronize the Publishable Document Types
4. Configuring the Integration Server to Publish and Subscribe to Documents
Introduction . . . 48
Configure the Connection to the Broker . . . 48
Configuring Document Stores . . . . 49
Specifying a User Account for Invoking Services Specified in Triggers . . . 49
Configuring Server Parameters . . . . 50
Configuring Settings for a Document History Database . . . 53
Configuring Integration Server for Key Cross-Reference and Echo Suppression . . . 53
Configuring Integration Server to Handle Native Broker Events . . . 53
4 Configuring the Integration Server to Publish and Subscribe to Documents
Introduction
Before you can begin to publish and subscribe to documents, whether locally or using a Broker, you need to specify settings for some of the Integration Server components and services. Specifying settings consists of using the Integration Server Administrator to:
Configure the connection to the Broker (if publishing or subscribing to documents on the Broker).
Configure the document stores where the Integration Server will save documents until they can be published or processed.
Specify a user account for executing services specified in triggers.
Configure a document history database.
Configure a key cross‐referencing and echo suppression database.
Configure settings for handling native Broker events.
Configure other Integration Server parameters that can affect a publish‐and‐subscribe solution.
Configure the Connection to the Broker
If you want to use the Broker as the messaging facility for distributing documents you need to configure the Integration Server’s connection to the Broker. Although you do not need to connect the Broker to the Integration Server during development, you must do so before you can publish or subscribe to documents across the enterprise. If you do not configure a connection to the Broker, the Integration Server publishes all documents locally.
For detailed information about configuring a connection to the Broker, see “Configuring the Server” in the webMethods Integration Server Administrator’s Guide. For more
information about the Broker, see the webMethods Broker Administrator’s Guide.
Note: With the exception of configuring the connection to the Broker, you do not have to configure these settings until you have finished developing an integration solution and are ready to test the publication/subscription of a document.
Note: If you switch your Integration Server connection from one Broker to a Broker in another territory, you may need to synchronize your publishable document types with the new Broker. Switching your Broker connection is not recommended or supported. For more information about synchronizing publishable document types, see “Synchronizing Publishable Document Types” on page 74.
4 Configuring the Integration Server to Publish and Subscribe to Documents
Configuring Document Stores
The Integration Server uses document stores to save published documents to disk or to memory while the documents are in transit or waiting to be processed. The Integration Server maintains three document stores for published documents.
Default document store. The default document store contains documents delivered to the client ID of the Integration Server. When the Integration Server retrieves documents delivered to its client ID, the server places the documents in the default document store. Documents remain in the default document store until the
dispatcher determines which triggers subscribe to the document. The dispatcher then moves the documents to the trigger queues for the subscribing triggers.
Trigger document store. The trigger document store contains documents waiting to be processed by triggers. The server assigns each trigger a queue in the trigger document store. A document remains in the trigger queue until the server successfully processes the document.
The Integration Server saves most documents it retrieves from the Broker in a trigger document store located in memory. However, the Integration Server saves documents delivered to the default client in a trigger document store located on disk. The
Integration Server also saves locally published documents in a trigger document store located on disk.
Outbound document store. The outbound document store contains documents waiting to be sent to the Broker. The Integration Server places documents in the outbound document store when the configured Broker is not available. When the connection to the Broker is restored, the server empties the outbound document store by sending the saved documents to the Broker.
Using the Integration Server Administrator, you can configure properties for each document store. For example, you can determine the store locations and the initial store sizes.
Specifying a User Account for Invoking Services Specified in Triggers
When a client invokes a service via an HTTP request, the Integration Server checks the credentials and user group membership of the client against the Execute ACL assigned to the service. The Integration Server performs this check to make sure the client is allowed to invoke that service. In a publish‐and‐subscribe situation, however, the Integration Server invokes the service when it receives a document rather than as a result of a client request. Because the Integration Server does not associate user credentials with a
published document, you can specify the user account for the Integration Server to use when invoking services associated with triggers.
4 Configuring the Integration Server to Publish and Subscribe to Documents
For more information about setting the Run Trigger Service As User property, see the webMethods Integration Server Administrator’s Guide.
Configuring Server Parameters
Integration Server has server parameters that you can configure. Many parameters are set
4 Configuring the Integration Server to Publish and Subscribe to Documents
wm.server.dispatcher:deleteExpiredUUID executes and removes expired document history entries.
Note: Multiple triggers can subscribe to the same document. Integration Server places the document in any subscribing trigger queue that is not at capacity.
4 Configuring the Integration Server to Publish and Subscribe to Documents
watt.server.publish.usePipelineBrokerEvent
Specifies whether Integration Server should bypass encoding that is normally performed when documents are published to the Broker. For more information about when to set this property, see “Configuring Integration Server to Handle Native Broker Events” on page 53.
watt.server.publish.validateOnIS
Specifies whether Integration Server validates published documents all the time, never, or on a per document type basis. For more information about document validation, see
“Specifying Validation for a Publishable Document Type” on page 68.
watt.server.trigger.interruptRetryOnShutdown
Specifies whether or not a request to shutdown the Integration Server interrupts the retry process for a trigger service. The default is “false”. For more information about
interrupting trigger service retries, see “Trigger Service Retries and Shutdown Requests”
on page 141.
watt.server.trigger.keepAsBrokerEvent
Specifies whether Integration Server should bypass decoding that is normally performed when documents are retrieved from the Broker on behalf of a trigger. For more
information about when to set this property, see “Configuring Integration Server to Handle Native Broker Events” on page 53.
watt.server.trigger.local.checkTTL
Specifies a comma‐delimited list of triggers to exclude from the Trigger Management pages in the Integration Server Administrator. The Integration Server also excludes these resource monitoring services, see Appendix B, “Building a Resource Monitoring Service”.
4 Configuring the Integration Server to Publish and Subscribe to Documents
the Document History Database Is Not Available?” on page 155 and “Document Resolver Service and Exceptions” on page 157.
watt.server.trigger.removeSubscriptionOnReloadOrReinstall
Specifies whether Integration Server deletes document type subscriptions for triggers when the package containing the trigger reloads or an update of the package is installed.
watt.server.xref.type
Specifies where key cross referencing and echo suppression information is written.
Configuring Settings for a Document History Database
To provide exactly‐once processing for one or more triggers, you need to use a document history database to maintain a record of all the documents processed by those triggers.
You or the server administrator must create the Document History database component and connect it to a JDBC connection pool. For instructions, see the webMethods Installation Guide.
Configuring Integration Server for Key Cross-Reference and Echo Suppression
If you intend to use the key cross‐reference and echo suppression services to perform data synchronizations, you must store the cross‐reference keys and the latching status information in the embedded internal database or in an external RDBMS. Integration Server writes cross‐reference data to the embedded internal database by default. If you want to store the key cross‐reference information in an external RDBMS, you must create the Cross Reference database component and connect it to a JDBC connection pool. For instructions, see the webMethods Installation Guide.
For more information about the key cross‐reference and echo suppression services, see Chapter 10, “Synchronizing Data Between Multiple Resources”.
Configuring Integration Server to Handle Native Broker Events
By default, Integration Server encodes and decodes data it passes to and from the Broker as follows:
When Integration Server sends a document to the Broker, it first encodes the document (IData object) into a Broker event.
When Integration Server receives a document from the Broker, it decodes the Broker event into an IData object.
4 Configuring the Integration Server to Publish and Subscribe to Documents
In some situations, you may want to bypass this encoding or decoding step on
Integration Server and instead send and receive “native” Broker events to and from the Broker. These situations are when you:
Migrate Enterprise business logic to Integration Server.
Use custom Broker clients written in Java, C, or COM/ActiveX.
You configure Integration Server to handle native Broker events by setting server parameters.
1 Open the Integration Server Administrator if it is not already open.
2 In the Settings menu of the Navigation panel, click Extended.
3 Look for the watt.server.publish.usePipelineBrokerEvent property and change its value to
true.
If the watt.server.publish.usePipelineBrokerEvent property is not displayed, see the webMethods Integration Server Administrator’s Guide for instructions on displaying extended settings.
4 Look for the watt.server.publish.validateOnIS property and change its value to never. 5 If Integration Server is retrieving documents from the Broker on behalf of a trigger,
look for the watt.server.trigger.keepAsBrokerEvent property and change its value to true. 6 Click Save Changes.
7 Restart Integration Server.
To configure Integration Server to handle native Broker events
Note: If you set the watt.server.trigger.keepAsBrokerEvent property to true and the watt.server.publish.validateOnIS property to always or perDoc, you will receive validation errors.