The webMethods messaging provider used by the publishing service.The webMethods messaging provider used by the publishing service.Whether or not the client side queue is configured.For Universal Messaging, you configure the client side queue on a per connection alias basis. The value of the Enable CSQ check box for the Universal Messaging connection alias used by the publishing service determines whether or not a client side queue is used when the Universal Messaging server is not available.For Broker, the value of the watt.server.publish.useCSQ parameter determines whether or not the client side queue is used when the Broker is not available. When the watt.server.publish.useCSQ parameter is set to always, the default, Integration Server places documents in the client side queue. When the watt.server.publish.useCSQ parameter is set to never, Integration Server throws a ServiceException.For information about configuring the client side queues for Universal Messaging and Broker, see the section About the Outbound Document Store in the webMethods Integration Server Administrator’s Guide.
About the Outbound Document Store.The storage type for the publishable document type of which an instance is being published.
Step | Description |
1 | A publishing service sends a document to the dispatcher (or an adapter notification publishes a document when an event occurs on the resource the adapter monitors). If validation is configured for the publishable document type, Integration Server validates the document against its publishable document type before sending the document to the dispatcher. If the document is not valid, the service returns an exception specifying the validation error. |
2 | The dispatcher detects that the webMethods messaging provider is not available, Integration Server, specifically the publishing service, waits for the connection to the messaging provider to be re-established. When Universal Messaging is the webMethods messaging provider, Integration Server waits up to the length of time specified for the Publish Wait Time While Reconnecting field for the Universal Messaging connection alias used by the publishing service.When Broker is the webMethods messaging provider, Integration Server waits 400 milliseconds for the Broker to become available.If the webMethods messaging provider is not available after the specified wait time elapses, Integration Server does one of the following depending on the storage type of the document: If the document is guaranteed and the client side queue is configured, the dispatcher routes the document to the client side queue.If the document is guaranteed and the client side queue is not configured, Integration Server throws an ISRuntimeException.If the document is volatile, the dispatcher discards the document and the publishing service throws an exception.Integration Server executes the next step in the publishing service. |
3 | When Integration Server re-establishes a connection to the webMethods messaging provider, Integration Server automatically sends the documents from the client side queue to the messaging provider When Universal Messaging is the messaging provider, Integration Server determines how to drain the client side queue based on the value of the Drain CSQ in Order check box for the Universal Messaging connection alias used by the publishing service. When the Drain CSQ in Order check box is selected, Integration Server continues to write new messages to the client side queue until the client side queue is completely drained.When the Drain CSQ in Order check box is not selected, Integration Server sends new messages directly to the Universal Messaging server while it drains the client side queue.When Broker is the messaging provider, Integration Server determines how to drain the client side queue based on the value of the watt.server.publish.drainCSQInOrder parameter determines how the outbound store is emptied. When watt.server.publish.drainCSQInOrder is set to true (the default), Integration Server sends all newly published documents (guaranteed and volatile) to the client side queue until the outbound store has been emptied. This allows Integration Server to maintain publication order.When watt.server.publish.drainCSQInOrder is set to false, Integration Serversends new messages directly to the Broker while it drains the client side queue. |
4 | The webMethods messaging provider examines the storage type for the document, determines that it is guaranteed and stores the document in memory and on disk. |
5 | The webMethods messaging provider routes the document to subscribers by doing one of the following: If the document was published (broadcast), the webMethods messaging provider identifies subscribers and enqueues a copy of the document for each subscriber.If the document was delivered, the webMethods messaging provider enqueues the document for the destination specified in the delivery request.The Broker places documents in a queue for a subscriber. Universal Messaging places documents on a channel. A document remains enqueued on the webMethods messaging provider until it is picked up by the subscriber. If the time-to-live for the document elapses, the webMethods messaging provider discards the document. For more information about setting time-to-live for a publishable document type, see webMethods Service Development Help. If there are no subscribers for the document and the messaging provider has been configured to handle dead letters (sometimes called dead events), the webMethods messaging provider routes the document to the dead letter queue or dead event store. For more information about configuring the messaging provider to handle documents for which there are no subscribers, refer to the documentation for the webMethods messaging provider that is in use. Note: If the Broker is the webMethods messaging provider and a deadletter subscription exists for the document, the Broker deposits the document in the queue containing the deadletter subscription. For more information about creating deadletter subscriptions, see webMethods Service Development Help. |
6 | The webMethods messaging provider enqueues the document for subscribers. Integration Server removes the document from the client side queue. |
You can set the capacity of the client side queue and the outbound document store.For the client side queue for a Universal Messaging connection alias, the Maximum CSQ Size field determines the maximum number of documents that can be in the queue. When the client side queue is at capacity, publishing services that use this connection alias will end with an ISRuntimeException.For the outbound document store used with Broker, the watt.server.control.maxPersist server configuration parameter determines the maximum number of documents that can be in the store while the Broker is unavailable. After the outbound document store reaches capacity, the server "blocks" or "pauses" any threads that are executing services that publish documents. The threads remain blocked until Integration Server begins draining the outbound document store.To empty the outbound document store more rapidly, Integration Server sends the documents in batches instead of one at a time. You can use the Maximum Documents to Send per Transaction field to specify the maximum number of documents that Integration Server sends from the outbound document store to the Broker. The Maximum Documents to Send per Transaction field is located on the Settings > Resources > Store Settings > Edit Document Store Settings page in Integration Server Administrator.If the initial attempt to publish the document to Universal Messaging from the CSQ fails, Integration Server makes subsequent attempts until the document is published successfully or Integration Server makes the maximum attempts specified in watt.server.messaging.csq.maxRedeliveryCount. If Integration Server makes the maximum redelivery attempts and all attempts have failed, Integration Server discards the document.If the initial attempt to publish the document to Broker from the CSQ fails, Integration Server makes subsequent attempts until the document is published successfully or Integration Server makes the maximum attempts specified in watt.server.publish.maxCSQRedeliveryCount. Each attempt to publish to Broker from the CSQ is considered a redelivery attempt Integration Server. After Integration Server makes the specified number of attempts to transmit a document from the CSQ to the Broker and all attempts fail, the audit subsystem logs the document and assigns it a status of STATUS_TOO_MANY_TRIES.If Integration Server publishes documents to a Universal Messaging server on which the PauseServerPublishing configuration parameter is set to true, publishing fails with an nPublishPauseException. Integration Server handles the nPublishPauseException by proceeding as if the messaging connection alias is unavailable.You can configure publishable document types and Integration Server so that Integration Server does not validate documents when they are published. For more information about validating publishable document types, see webMethods Service Development Help.