Technical Interview Questions and Answers :: WebMethod
=> the publishing flow service stops executing while it waits for a response. When the service receives a reply document from the specified client, the service resumes execution
=> In an asynchronous request/reply, the publishing flow service continues executing after publishing the requested document. That is, the publishing service does not wait for a reply before executing the next step in the flow service. The publishing flow service must invoke a separate service to retrieve the reply document.
Step 1: The dispatcher on the Integration Server requests documents from the default client’s queue on the Broker.
Note: The default client is the Broker client created for the Integration Server.The Broker places documents in the default client’s Broker queue only if the publisher delivered the document to the Integration Server’s client ID.
Step 2: The thread retrieves documents delivered to the default client in batches.The number of documents the thread retrieves at one time is determined by the capacity and refill level of the default document store and the number of documents available for the default client on the Broker.
Step 3: The dispatcher places a copy of the documents in memory in the default document store.
Step 4: The dispatcher identifies subscribers to the document and routes a copy of the document to each subscriber’s trigger queue.In the case of delivered documents, the Integration Server saves the documents to a trigger queue. The trigger queue is located within a trigger document store that is saved on disk.
Step 5: The Integration Server removes the copy of the document from the default document store and, if the document is guaranteed, returns an acknowledgement to the Broker. The Broker removes the document from the trigger client queue.
Step 6: The dispatcher obtains a thread from the server thread pool, pulls the document from the trigger queue, and evaluates the document against the conditions in the trigger.
Note: If exactly-once processing is configured for the trigger, the Integration Server first determines whether the document is a duplicate of one already processed by the trigger. The Integration Server continues processing the document only if the document is new.
Step 7: If the document matches a trigger condition, the Integration Server executes the trigger service associated with that condition.If the document does not match a trigger condition, the Integration Server sends an acknowledgement to the trigger queue, discards the document (removes it from the trigger queue), and returns the server thread to the server thread pool. The Integration Server also generates a journal log message stating that the document did not match a condition.
Step 8: After the trigger service executes to completion (success or error), one of the followings occurs:
* If the trigger service executed successfully, the Integration Server returns an acknowledgement to the trigger queue (if this is a guaranteed document), removes the document from the trigger queue, and returns the server thread to the thread pool.
* If a service exception occurs, the trigger service ends in the error and the Integration Server rejects the document, removes the document from the trigger queue, returns the server thread to the thread pool, and sends an error document to indicate that an error has occurred. If the document is guaranteed, the Integration Server returns an acknowledgement to the trigger queue. The trigger queue removes its copy of the guaranteed document from storage.
* If a transient error occurs during trigger service execution and the service catches the error, wraps it and re-throws it as a run-time exception, then the Integration Server waits for the length of the retry interval and re-executes the service using the original document as input. If the Integration Server reaches the maximum number of retries and the trigger service still fails because of a transient error, the Integration Server treats the last failure as a service error.
Local publishing refers to the process of publishing a document within the Integration Server. Only subscribers located on the same Integration Server can receive and process the document. In local publishing, the document remains within the Integration Server.There is no Broker involvement.Local publishing occurs when the service that publishes the document specifies that the document should be published locally or when the Integration Server is not configured to connect to a Broker.
Note: If the dispatcher detects that the document is a duplicate of one already in the trigger queue, the dispatcher discards the document. The dispatcher detects duplicate documents using the universally unique identifier (UUID) for the document.
A publishable document type is a named schema-like definition that describes the structure and publication properties of a particular kind of document. Essentially, a publishable document type is an IS document type with specified publication properties such as storage type and time-to-live.
Adapter notifications determine whether an event has occurred on the adapter's resource and then sends the notification data to the Integration Server in the form of a published document. There are two types of adapter notifications: polling notifications, which poll the resource for events that occur on the resource, and listener notifications, which work with listeners to detect and process events that occur on the adapter resource.For example, if you are using the JDBC Adapter and a change occurs in a database table that an adapter notification is monitoring, the adapter notification publishes a document containing data from the event and sends it to the Integration Server.
The time-to-live value for a publishable document type determines how long instances of that document type remain on the Broker. The time-to-live commences when the Broker receives a document from a publishing Integration Server. If the time-to-live expires before the Broker delivers the document and receives an acknowledgement of document receipt, the Broker discards the document. This happens for volatile as well as guaranteed documents.
Using the publishing services, you can create services that publish or deliver documents locally or to the Broker. The publishing services are located in the WmPublic package.
|pub.publish:deliver||Delivers a document to a specified destination.|
|pub.publish:deliverAndWait||Delivers a document to a specified destination and waits for a response.|
|pub.publish:publish||Publishes a document locally or to a configured Broker.Any clients (triggers) with subscriptions to documents of this type will receive the document.|
|pub.publish:publishAndWait||Publishes a document locally or to a configured Broker and waits for a response. Any clients (triggers) with subscriptions for the published document will receive the document.|
|pub.publish:reply||Delivers a reply document in answer to a document received by the client.|
|pub.publish:waitForReply||Retrieves the reply document for a request published asynchronously.|
Triggers establish subscriptions to publishable document types and specifies how to process instances of those publishable document types. When you build a trigger, you create one or more conditions. A condition associates one or more publishable document types with a single service. The publishable document type acts as the subscription piece of the trigger. The service is the processing piece. When the trigger receives documents to which it subscribes, the Integration Server processes the document by invoking the service specified in the condition. Triggers can contain multiple conditions.
* The trigger contains at least one condition.
* Each condition in the trigger specifies a unique name.
* Each condition in the trigger specifies a service.
* Each condition in the trigger specifies one or more publishable document types.
When you create a join condition (a condition with two or more publishable document types), you need to specify a join time-out. A join time-out specifies how long the Integration Server waits for the other documents in the join condition. The Integration Server uses the join time-out period to avoid deadlock situations (such as waiting for a document that never arrives) and to avoid duplicate service invocation.The Integration Server starts the join time-out period when it pulls the first document that satisfies the join condition from the trigger queue.
The Integration Server contains a trigger document store in which it saves documents waiting for processing. The Integration Server assigns each trigger a queue in the trigger document store. A document remains in the trigger queue until the server determines which trigger condition the document satisfies and then executes the service specified in that condition. You can determine the capacity of each trigger’s queue in the trigger queue. The Capacity indicates the maximum number of documents that the Integration Server can store for that trigger. You can also specify a Refill level to indicate when the Integration Server should retrieve more documents for the trigger. The difference between the Capacity and the Refill level determines up to how many documents the Integration Server retrieves for the trigger from the Broker. For example, if you assign the trigger queue a Capacity of 10 and a Refill level of 4, the Integration Server initially retrieves 10 documents for the trigger. When only 4 documents remain to be processed in the trigger queue, the Integration Server retrieves up to 6 more documents. If 6 documents are not available, the Integration Server retrieves as many as possible.
In the Properties panel, under Trigger queue, in the Capacity property, type the maximum number of documents that the trigger queue can contain. The default is 10.3 In the Refill level property, type the number of unprocessed documents that must remain in this trigger queue before the Integration Server retrieves more documents for the queue from the Broker. The default is 4. The Refill level value must be less than or equal to the Capacity value.
Your responses will be stronger if you prepare well in advance for Webmethod Interview Questions, get most frequently asked top Basic and Advanced Webmethods interview questions and answers with detailed explanation.
This section covers Webmethods Interview Questions Accenture Webmethods Developer Interview Questions for freshers and experienced. It helps job seekers who are about to attend Interview for Webmethod Profile.
You can Compile a list of the Top/Favorite/Frequently asked Interview Questions/Answers and add to your "Reading List" and refer your Reading list questions whenever you want.