WebMethods , REPEAT Step

REPEAT Step :
The REPEAT step allows you to conditionally repeat a sequence of child steps based on the success or
failure of those steps.You can use REPEAT to :
. Re-excute (retry) a set of steps if any step within the set fails.
.Re-execute a set of steps until one of the steps within the set fails.

.Specifying the REPEAT Condition : Repeat on (FAILURE or SUCCESS) .

.Specifying the REPEAT Counter :

0 : does not re-execute children.
Any value > 0 : re-execute children up to this number of times.
-1 or blank : re-execute children as long as the specified Repeat on condition is true.

Important :
note that the children of a REPEAT always execute at least once. The Counter property specifies the
maximum number the children will be re-executed.

Using REPEAT to Retry a Failed Step

If your flow invokes services that access external systems, you can use the REPEAT step to accommodate
network errors, such as busy servers or connection errors, at run time. If you use the REPEAT step for
this purpose, keep the following points in mind:
􀂄 The following types of failures satisfy the FAILURE condition:
􀂄 Expiration of a child step’s Timeout limit
􀂄 An exception thrown by a Java service
􀂄 A document query that returns an unpermitted null value
􀂄 If you specify multiple children under a REPEAT step, the failure of any one of the children will cause
the entire set of children to be re-executed.
􀂄 The REPEAT step immediately exits a set of children at the point of failure (that is, if the second child in
a set of three fails, the third child is not executed).
􀂄 When Repeat on is set to FAILURE, the failure of a child within a REPEAT step does not cause the
REPEAT step itself to fail unless the Count limit is also reached.
􀂄 The Timeout property for the REPEAT step specifies the amount of time in which the entire REPEAT
step, including all of its possible iterations, must complete. When you use REPEAT to retry on failure,
you may want to leave the Timeout value at 0 (no limit) or set it to a very high value. You can also set
the property to the value of a pipeline variable by typing the name of the variable between % symbols.
􀂄 As a developer, you must be thoroughly familiar with the processes you include within a REPEAT
step. Make certain that the child steps you specify can safely be repeated in the event that a failure
occurs. You don’t want to use REPEAT if there is the possibility that a single action, such as accepting an
order or crediting an account balance, could be applied twice.

Using REPEAT to Retry a Successful Step

Apart from using REPEAT to retry a failed step, you can also use it as a looping device to repeat a series
of steps until a failure occurs.
If you use the REPEAT step to re-execute successful child steps, keep the following points in mind:
􀂄 The success condition is met if all children of the REPEAT step execute without returning a single
exception.
􀂄 If one child in the set fails, the REPEAT step exits at the point of failure, leaving the remaining children
unexecuted.
􀂄 The failure of a child does not cause the REPEAT step to fail; it merely ends the loop.
(In this case, the REPEAT step itself succeeds and execution of the flow proceeds normally).

Explain in and out how does Trading Network works whe n an

transaction is submitted

Answer:
Trading Networks uses the information you specify at design time to process a document at run
time. It uses:

DESIGN TIME

* Sender's profiles to ensure the user sending the document is an active partner in your network

* Receiver's profiles to obtain information specific to the receiving partner for processing document
(e.g., the partner's HTTP hostname and port number if delivering a document via HTTP)
* TN document types to recognise the type of document that was sent and to determine document
attributes to associate with the document

* Processing rules to determine the actions you want Trading Networks to perform against the
inbound document

The run-time processing that Trading Networks performs for an inbound document can be divided
into four areas:

RUN TIME PROCESSING

* Recognition processing, which is determining the TN document type that matches the inbound
document using the identification information that you defined in TN document types, and after
locating the matching TN document type, obtaining the values of the document attributes that you
specified in the TN document type.

* Processing rule selection, which is determining the processing rule to use for the inbound
document based on the criteria that you defined in processing rules.

* Pre-processing actions, which is performing the pre-processing actions that you defined in the TN
document type and/or processing rule.

* Processing actions, which is performing the processing actions that you defined in the processing
rule.

Preprocessing Rule - Verify Digital Signature, Validate Structure Of Document, Check Duplication,
Save.

Processing Action - Execute a Service, Send an alert e-mail, Change the user status, Deliver the
document to Receiver, Respond with a message.

DELIVERY TIME PROCESSING

Trading Networks can deliver documents using one of the following delivery options that you specify
with the Deliver Document By processing action in a processing rule:

* Immediate Delivery. Trading Networks attempts to deliver a document directly to the receiving
partner. You can create immediate delivery methods using the standard delivery methods such as
HTTP and FTP. In addition, you can create immediate delivery methods using custom delivery
services.

* Scheduled Delivery. Trading Networks queues documents to be delivered at scheduled times. You
define scheduled delivery queues in Trading Networks. When you define the queue, you associate
both a schedule and a scheduled delivery service with the queue. At the time(s) the schedule
indicates, Trading Networks invokes the scheduled delivery service to act on the documents in the
queue to deliver them. Trading Networks provides one built-in scheduled delivery service. You can
add additional scheduled delivery services to meet your needs. Â

* Queued for polling. Trading Networks places the document in an internally-defined queue. The
receiving partner later polls for documents and Trading Networks

returns all the documents in the queue for which that partner is the receiver.

* Receiver's Preferred Protocol. Trading Networks looks up the receiver's profile and uses the
delivery method that is identified in the profile as the preferred delivery method.The preferred
delivery method can be any of the immediate delivery methods, scheduled delivery, or queued for
polling.