Hello,
Repeat Construct is used for repeating a piece of code or few lines.
For eg. DB connection. If I am using an insertion in DB, I can use a repeat step on it, with a condition of repeat when failure. So if the connection fails, it would repeat it again.
For more details, read the documentation as mentioned by Lanfir and Ambrish.
path = %wm install directory%/_documentation/Developer/UserGuide.
In addition to the the above post, repeat is very useful to implementing the same repeatitive block (piece of code) depending upon condtions eg. success/failure.
To implement Repeat:
Use Repeat flow step.
Use sequence (child flow of repeat) put all your logic which you want to repeat inside it.
Now if you know how many times you want to continue specify in repeat count (properties panel).
Repeating Condition – Lets say if you want to repeat all logic when there is no error happened in execution … then set repeat on success…
If you use this setting… your logic will repeat for count specified by you when no error happens in execution…
On contrary, u can set it to repeat on failure as well…
Hope it’s much clear to you now…
Note: if you are using repeat on success… specify some + integeral value and always use exit to implement condition to come out from loop to avoid infinite execution.
Can refer to steps below, was there in one of the posts…
The list below assumes you need to create or expose dozens of web services and that you are not using an XML security appliance or a web services intermediary or web services management tool such as ServiceNet 6.5.
Study and become familiar with the general web services interoperability best practices captured in the WS-I Basic Profile 1.0 and WS-I Basic Security Profile 1.0. You will not be able to easily adhere to all of these best practices using the current release of IS, but they will inform your decision making and identify interoperability issues that need to be managed.
Adopt a top-down, WSDL-first or, at least, message first approach to designing your web services rather than looking at a folder full of IS services and trying to figure out how to expose them consistently. An excellent book on this topic is Thomas Erl’s Service-Oriented Architecture: Concepts, Technology and Design.
Create web services using only SOAP document / literal style of messages for maximum interoperability
Design and build a custom SOAP processor that handles all processing of SOAP messages and allows your services to be invoked with only IS documents for input.
Provide some type of service metadata repository to be used by the custom SOAP processor for things like configuring some behaviors such as logging, auditing, schema validation, custom security requirements, etc. on an individual service basis. At the least this repository should hold the document types into which the payload of the soap request message should be place or against which the XML validation should be performed.
Adopt a WS-Security approach that fits the needs of your application and business requirements NOT one that happens to be supported by some vendor’s toolset. This may require building utilities to handle tasks such as XML signature and XML encryption as these basic services are not yet provided by Integration Server.
Give proper consideration to how your web services security approach should be integrated with your organization’s identify management solution. Leverage existing identity management tools where they exist and attempt to avoid island-of-automation solutions such as only using the IS identity information.
Don’t write the first line of web services code before you have invested in some decent XML Schema and web services testing tools. XML Spy is a defacto standard, but others will work nicely as well. Both SOAP Sonar Personal Edition and PocketSoap TCPTrace are free and highly useful. Other possibilities are Parasoft SOATest, Mercury ServiceTest and Solstice Software. The new Eclipse WTP plugins also show promise.
Understand what development tools the consumers of your services will most likely use and plan to generate test harnesses that use those tools.
Build and deploy simple “ping” tests early in the development cycle. While these services should perform something extremely simple such as returning a timestamp, they should use the same security approach and protocol (e.g. HTTPS) as the production services will use.
Invest in a comprehensive web services testing suite and build regression tests in parallel (or before) developing the services themselves. One good place to start is Solstice Software.
Hope this helps you. There are many related posts to it, can also search.