How to create a BPEL dynamic process?

Question

Hi gurus,
We have encountered the following scenario, hope somebody can help!
The client will manage some provisioning activities with an end system that will service them, BPEL is required to be the "Activity Manager", and handle these as they come; meaning, the client will send an array message describing the order in sequence on how they should be sent to the end system. This activities can have dependencies between them, also defined within the input message. The following is a muck up example of input message structure:
<ActivityOrder>
<!-- Some descriptions about the ActivityOrder>
<Id/>
<Status/>
<DateInitiated/>
<!-- This can have N number of ListActivity descriptions-->
<ListActivity>
<ListAtivityHeader>
<SequenceNumber/>
<Dependency/>
<ActivityId/>
<Status/>
<Description/>
<!-- ListActivityItem will contain message details to send to partnerLink>
<ListActivityItem>
</ListActivityItem>
</ListActivity>
</ActivityOrder>
The order in which these activities are processed in BPEL will be dynamic, and they will be sent at run time, so to support this approach, a dynamic orchestration process will be needed on the integration layer. The client will send an array containing the sequential activities described by <SequenceNumber>, and also the dependencies between them, if that activity requires it, described by <Dependency> which will contain the sequence number that has to be completed before the current activity can be performed. After the end system resolves and replies to the activity requestin BPEL, an update must be sent to the client notifying status.
All these interactions are assynchronous and could take as long as 6-8 weeks. Is it technically feasable the implementation of the above requirements? If so, how can we accomplish this?
We are on SOA Suite 10.1.3.1
Regards,
Wilver
Edited by: user633514 on Feb 4, 2010 8:21 AM

Answer 1

Thanks for the reply, and yes, I have taken ideas from it that sample, but this is not the case I'm stating, parterLink is wellknown at design time, so its not a Dynamic partnerLink type of scenario since its the process flow the one that needs to be determined at run time. Dependant activities can't start until reply of the activity that it depends on has being received. How can I verify that an activity sent has being received?
I've been weightin options; Can't use flowN since there could exists dependencies between processes. It can be accomplished by doing a combination of logical while structures or to call recursively another bpel process that will manage the Invoke/Receive, depending on the nature of the flow. Is there any other way of doing this that we haven't seen? What are the pros and cons I could encounter? What is the best practice recommendation for such scenario?
Right now we have the following algorithm:
Channel Initiates process
Receive Input
While Message has Activity
If Activity has no Dependencies
Invoke CurrentActivityCreationService
End-If
Else
Set $receiveStatus = 'NO'
While Activity Dependancy NOT Received
Verify Activity Dependancy Receive Status (Where I get this info??)
Update $receiveStatus with the outcome of the Verify activity above
If $receiveStatus = 'NO'
Receive ActivityCreationServiceResponse
Update Channel
End-If
Else
Invoke CurrentActivityCreationService
Set $receiveStatus = 'NO'
End-Else
End-While
getNextActivity
End-Else
While Exist a Pending Activity Responses to be Received
Receive ActivityCreationServiceResponse
Update Channel
End-While
Invoke Channel Callback
The above algorithm creates me the following restrictions:
• Activities are needed to be sent sequentially ordered.
• Each activity may only have one dependency.
• An activity can never depend on another that is later in the sequence.
• Before sending activities that depend on previous one, it needs to know the state of that previous activity dependency, if already received or not.
• For better performance, all independent activities should be first in the sequence, and activities with dependancies last.
As usual most of these restriction are a hard sell since the activity stack will be tailored by a functional end user, so their not desired. Any fresh idea will be more than welcome, thanks for the time.
Regards, Wilver
Edited by: Wilver Cortes on Feb 5, 2010 6:34 AM
Edited by: Wilver Cortes on Feb 5, 2010 6:38 AM