Technical Interview Questions and Answers :: WebMethod
When building a trigger, you can specify a retry limit for the trigger service. The retry limit indicates the maximum number of times the Integration Server re-executes the trigger service when the trigger service fails because of a run-time exception. A run-time exception (specifically, an ISRuntimeException) occurs when the trigger service catches, and wraps a transient error and rethrows it as a run-time exception.
Within the publish-and-subscribe model, document processing is the process of evaluating documents against trigger conditions and executing the appropriate trigger services to act on those documents. The processing used by the Integration Server depends on the document storage type and the trigger settings. The Integration Server offers three types of document processing.
* At-least-once processing indicates that a trigger processes a document one or more times. The trigger might process duplicates of the document. The Integration Server provides at-least-once processing for guaranteed documents.
* At-most-once processing indicates that a trigger processes a document once or not at all. Once the trigger receives the document, processing is attempted but not guaranteed. The Integration Server provides at-most-once processing for volatile documents (which are neither redelivered nor acknowledged). The Integration Server might process multiple instances of a volatile document, but only if the document was published more than once.
* Exactly-once processing indicates that a trigger processes a document once and only once. The trigger does not process duplicates of the document. The Integration Server provides exactly-once processing for guaranteed documents received by triggers for which exactly-once properties are configured.
Note - At-least-once processing and exactly-once processing are types of guaranteed processing. In guaranteed processing, the Integration Server ensures that the trigger processes the document once it arrives in the trigger queue. The server provides guaranteed processing for documents with a guaranteed storage type.
The following section provides more information about how the Integration Server ensures exactly-once processing.
Note: Guaranteed document delivery and guaranteed document processing are not the same things. Guaranteed document delivery ensures that a document, once published, is delivered at least once to the subscribing triggers. Guaranteed document processing ensures that a trigger makes one or more attempts to process the document.
The redelivery count indicates the number of times the transport (the Broker or, for a local publish, the transient store) has redelivered a document to the trigger. The transport that delivers the document to the trigger maintains the document redelivery count. The transport updates the redelivery count immediately after the trigger receives the document. A redelivery count other than zero indicates that the trigger might have received and processed (or partially processed) the document before.
The document history database maintains a history of the guaranteed documents processed by triggers. The Integration Server adds an entry to the document history database when a trigger service begins executing and when it executes to completion(whether it ends in success or failure). The document history database contains document processing information only for triggers for which the Use history property is set to true.
The database saves the following information about each document:
* Trigger ID. Universally unique identifier for the trigger processing the document.
* Document UUID. Universally unique identifier for the document. The publisher is responsible for generating and assigning this number. (The Integration Server
automatically assigns a UUID to all the documents that it publishes.)
* Processing Status. Indicates whether the trigger service executed to completion or is still processing the document. An entry in the document history database has either a status of "processing" or a status of "completed." The Integration Server adds an entry with a "processing" status immediately before executing the trigger service. When the trigger service executes to completion, the Integration Server adds an entry with a
status of "completed" to the document history database.
* Time. The time the trigger service began executing. The document history database uses the same time for both entries it makes for a document. This allows the Integration Server to remove both entries for a specific document at the same time.
To determine whether a document is a duplicate of one already processed by the trigger, the Integration Server checks for the documentâ€™s UUID in the document history database. The existence or absence of the documentâ€™s UUID can indicate whether the document is new or a duplicate.
Join conditions are conditions that associate two or more document types with a single trigger service. Typically, join conditions are used to combine data published by different sources and process it with one service.
The join type that you specify for a join condition determines whether the Integration Server needs to receive all, any, or only one of the documents to execute the trigger service. The following table describes the join types that you can specify for a condition.
Join Type Description
All (AND) The Integration Server invokes the associated trigger service when the server receives an instance of each specified publishable document type within the join time-out period. The instance documents must have the same activation ID. This is the default join type.For example, suppose that a join condition specifies document types A and B and C. Instances of all the document types must be received to satisfy the join condition. Additionally, all documents must have the same activation ID and must be received before the specified join time-out elapses.
Any (OR) The Integration Server invokes the associated trigger service when it receives an instance of any one of the specified publishable document types.
For example, suppose that the join condition specifies document types A or B or C. Only one of these documents is required to satisfy the join condition. The Integration Server invokes the associated trigger service every time it receives a document of type A, B, or C. The activation ID does not matter. No time-out is
Only one (XOR) The Integration Server invokes the associated trigger service when it receives an instance of any of the specified document types. For the duration of the join time-out period, the Integration Server discards (blocks) any instances of the specified publishable document types with the same activation ID. For example, suppose that the join condition specifies document types A or B or C. Only one of these documents is required to satisfy the join condition. It does not matter which one. The Integration Server invokes the associated trigger service after it receives an instance of one of the specified document types. The integration Server continues to discard instances of any qualified document types with the same activation ID until the specified join time-out elapses.
The try-catch block works the same way as Java. It is 3 sequence step Main, Try and Catch block. You execute a sequence of steps, if you faced unexpected exception/error you skip the processing and execute the catch block.
To define the Try-Catch block, follow the following steps:
- Create a new flow service using SoftwareAG designer.
- Create a new sequence and call it 'Main'.
- Create another two sequence under the 'main' sequence; call them, 'Try', and 'catch'.
Go to the properties of each sequence and configure the 'exit on' as follows:
* 'Success' for the 'Main' sequence.
*'Failure' for the 'try' sequence.
* 'Done' for the catch sequence.
The main sequence has the try, and Catch sequences. So by defining the 'exit on' parameter of for the main to 'Success', this means that if the first sequence (Try) finished successfully then exit the sequence 'Main' and the 'Catch' Block/sequence will not be executed.
The 'Try' sequence is configured to 'exit on' = 'failure', which means if one step failed, all the steps following the failed step in the 'Try' block will not be executed, and the code will jump to execute the 'Catch' block/sequence.
The 'Catch' block is configured to 'exit on' = 'done' which means that each step in the 'Catch' block must be executed regardless of the result of each step.
We can loop over the flatfilename/recordWithNoId and map each of the fields to the insert adapter.
EAI - When you want to communicate with any application in one company (XYZ Ltd), that time you go with EAI
B2B - When the company (XYZ Ltd) want to communicate with other company(ABC Ltd), that time you go with B2B
Comunication, standards and cooperation are managed differently, depending on if you are connecting two application in a business, or if you are connecting two disparate businesses.
These statements provide control over use of transactions
START TRANSACTION or BEGIN start a new transaction.
COMMIT - commits the current transaction, making its changes permanent.
ROLLBACK - rolls back the current transaction, canceling its changes.
ROLLBACK TRANSACTION rolls back an explicit or implicit transaction to the beginning of the transaction, or to a savepoint inside the transaction. It also frees resources held by the transaction
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 CApgemini 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.