I’m trying to use a Repeat step on a registration system, and I’ve found that the scope of the repeat is reset at every retry.
Here’s the scenario:
A database stored procedure is called to register a client. If the username the client has chosen is not unique, a reponse is returned from the database which contains a choice of three alternative usernames.
The repeat step begins: The first of these three usernames is chosen automatically and inserted into the original request.
The stored procedure is called again. At this point, it is possible to return exactly the same error and a new choice of three usernames.
My problem is that the pipeline is reset at every repeat, which means that the choice of usernames is always the same.
Is it possible to preserve the pipeline between repeat steps?
If not, can anyone suggest an alternative approach to this scenario? I have toyed with the idea of a custom java service, but I may as well write the entire flow in java if that’s the only viable option.
1.0 Call SP to attempt to register user
2.0 If name taken:
2.1 Copy list returned from SP to new list altNames
2.2 LOOP over altNames
2.2.1 Call SP
2.2.2 If service succeeded
2.2.2.1 Set success flag
2.2.2.2 Exit from loop
2.3 If successFlag=false
2.3.1 Exit from flow with error (or deal with inability to register user)
Unfortunately that’d be a loop instead of a repeat, and as such it’d be limited to using only the three usernames returned from the first call. It means the loop would only execute three times, max, and would not be able to use any new set of usernames returned by the stored procedure.
That’s the main problem I’m trying to solve, if it is even possible via a Repeat.
Sounds like you are looking for a recursive solution.
Does the SP always suggest alternates or at some point does it return an empty list of alternatives? What does the SP return when it succeeds?
Assuming a Flow service getUsername exists that accepts a single username and returns a boolean registeredSuccessfully, a list of alternate names (optional) and whatever data is returned for a successful registration:
1.0 Invoke getUsername Service with desired name
2.0 Branch on registeredSuccessfully
2.1 false: invoke getUsername with altName[0]
2.2 true: return successful registration data
The implementation will vary depending on what the SP actually returns. Attempt to minimize calls to the SP and the size of the stack of recursive calls.
Yes, the SP will always return alternatives, based on an internal algorithm. However, those alternatives are not guaranteed to be unique.
We’re getting away from the original intent of my question though: is there a way to preserve the values returned within a repeat step, or will webMethods always reset at the beginning of each retry?