Technical Interview Questions and Answers :: WebMethod

Data Error - An error that arises due to invalid data, illegal character or invalid data format.



Transient Error - an error that arises from a condition that might be resolved quickly, such as the unavailability of a resource due to network issues or failure to connect to a database. You can use webMethods Monitor to find and resubmit documents with a status of FAILED.
Ex. java.net.SocketTimeoutException.

A startup service is one that Integration Server automatically executes when it loads a package into memory.

Drop pipeline is an explicit cleanup. It is a request for the pipeline to remove a variable from the available list of variables and make the object it refers to available for garbage collection by the Java Virtual Machine.

Delete is purely a design-time operation to remove the variable from the current view. It is only of use if you have created a variable that you didn't mean to create. If you delete a variable that was there because it was previously in the pipeline when you change the view in developer you will see the variable appear again.

You can create only one join condition in a trigger, but a trigger can contain any number of simple conditions.

You can use the lexical relational operators to create filters that compare string values.

object.pub.invoke.full path of flow service.

Step 1: A publishing service on the Integration Server sends a document to the dispatcher (or an adapter notification publishes a document when an event

occurs on the resource the adapter monitors).Before the Integration Server sends the document to the dispatcher, it validates

the document against its publishable document type. If the document is not valid, the service returns an exception specifying the validation error.

Step 2: The dispatcher obtains a connection from the connection pool. The connection pool is a reserved set of connections that the Integration Server uses to publish documents to the Broker. To publish a document to the Broker, the Integration Server uses a connection for the default client.

Step 3: The dispatcher sends the document to the Broker.

Step 4: The Broker examines the storage type for the document to determine how to store the document.

* If the document is volatile, the Broker stores the document in memory.

* If the document is guaranteed, the Broker stores the document in memory

and on disk.

Step 5: The Broker routes the document to subscribers by doing one of the following:

* If the document was published (broadcast), the Broker identifies subscribers and places a copy of the document in the client queue for each subscriber.

* If the document was delivered, the Broker places the document in the queue for the client specified in the delivery request.

* If there are no subscribers for the document, the Broker returns an acknowledgement to the publisher and then discards the document.

A document remains in the queue on the Broker until it is picked up by the subscribing client. If the time-to-live for the document elapses, the Broker

discards the document.

Step 6: If the document is guaranteed, the Broker returns an acknowledgement to the dispatcher to indicate successful receipt and storage of the document. The

dispatcher returns the connection to the connection pool.

Step 7: The Integration Server returns control to the publishing service, which executes the next step.

Step 1: A publishing service on the Integration Server sends a document to the dispatcher (or an adapter notification publishes a document when an event occurs on the resource the adapter monitors).Before the Integration Server sends the document to the dispatcher, it validates the document against its publishable document type. If the document is not valid, the service returns an exception specifying the validation error.

Step 2: The dispatcher detects that the Broker is not available and does one of the followings depending on the storage type of the document:

* If the document is guaranteed, the dispatcher routes the document to the outbound document store on disk.

* If the document is volatile, the dispatcher discards the document and the publishing service throws an exception. The Integration Server executes the next step in the publishing service.

Step 3: When the Integration Server re-establishes a connection to the Broker, the Integration Server obtains a single connection from the connection pool

Step 4: The Integration Server automatically sends the documents from the outbound document store to the Broker. To empty the outbound document store more

rapidly, the Integration Server sends the documents in batches instead of one at a time.

Note: The Integration Server uses a single connection to empty the outbound document store to preserve publication order.

Step 5: The Broker examines the storage type for the document, determines that it is guaranteed and stores the document in memory and on disk.

Step 6: The Broker routes the document to subscribers by doing one of the following:

* If the document was published (broadcast), the Broker identifies subscribers and places a copy of the document in the client queue for each subscriber.

* If the document was delivered, the Broker places the document in the queue for the client specified in the delivery request.

* If there are no subscribers for the document, the Broker returns an acknowledgement to the publisher and then discards the document. A document remains in the queue on the Broker until the subscribing client picks it up. If the time-to-live for the document elapses, the Broker discards the document.

Step 7: The Broker returns an acknowledgement to the Integration Server to indicate successful receipt and storage of the guaranteed document. The Integration Server removes the document from the outbound document store.

Notes:

i) After the connection to the Broker is re-established, the Integration Server sends all newly published documents (guaranteed and volatile) to the outbound document store until the outbound store has been emptied. This allows the Integration Server to maintain publication order. After the Integration Server empties the outbound document store, the Integration Server resumes publishing documents directly to the Broker.

ii) If the Integration Server makes 4 attempts to transmit a document from the outbound document store to the Broker and all attempts fail, the audit subsystem logs the document and assigns it a status of STATUS_TOO_MANY_TRIES.

iii) If a transient error occurs while the Integration Server publishes a document, the audit subsystem logs the document and assigns it a status of FAILED.

IS sorts by trigger conditions but when 2 or more condition are same, it can't decide which one to choose from. So by default it uses the first condition.

The processing mode for a trigger determines whether the Integration Server processes documents in a trigger queue serially or concurrently. In serial processing,the Integration Server processes the documents one at a time in the order in which the documents were placed in the trigger queue. In concurrent processing, the Integration Server processes as many documents as it can at one time, but not necessarily in the same order in which the documents were placed in the queue.