chained execution - pageflow

11 views
Skip to first unread message

Harald

unread,
Feb 17, 2010, 2:39:15 AM2/17/10
to tempo-dev
Hi Nico,

Thanks for your quick answer!

We are planning to implement a process-based web-application for call-
center agents communicating with the customer (enduser) to find out
which problem the enduser has with phone- and internet services. To
surround the customers problem our web-application shows the call-
center agent the questions (create an intalio task) they have to ask
the customer.  The call-center agent enters the answer (complete the
intalio task). Then the bpmn-process decides on this answer what next
question is raised (create next task with chained exection) or what
webservice is called for getting further infos from backend-systems to
show the agent.

So our web-application shows the call-center agent question for
question, the question/answer history and additional infos from the
backend (webservice calls).

The process and forms behind the web-application should be easily
maintainable for editors using bpmn and ajax builder.

It would be great if you have tips, trick or best-practices for me.

Thanks, Harald

> -----Ursprüngliche Nachricht-----
> Von: Nicolas Modrzyk [mailto:ni...@intalio.com]
> Gesendet: Mittwoch, 17. Februar 2010 07:42
> An: Reinmüller Harald
> Betreff: Re: PageFlowTests at github
>
> Hi,
>
> Thank you for your email.
> Should be pretty much the same.
> Those examples I made mostly on my own time, and thought page flow was
> more easy to understand than the official Chained Execution.
>
> Post on the list when you have question so others can reply as well ;)
>
> What kind of application are you looking to develop ?
>
> Nico
>
> 2010/2/17 Reinmüller Harald <Harald.Re...@cirquent.de>:
>> Hi Nico,
>>
>> I'm just starting a new intalio project using intalio tempo and
>> intalio ajax mainly as a pageflow engine using the workflow pattern "chained execution".
>>
>> Therefore I was looking for examples and best practices and found
>> your PageFlowTests at
>> http://github.com/hellonico/tempodevprocesses/tree/master/PageFlowTes
>> ts/
>>
>> Can you please tell me the difference between "chained execution" and
>> your pageflow tests?
>>
>> Thanks in advance,
>> Harald

Nicolas Modrzyk

unread,
Feb 17, 2010, 10:45:09 PM2/17/10
to temp...@googlegroups.com
Hi Harald,

This is more of an end-to-end call for implementation on top of our
technologies.

While the tempo-dev list can help you on development questions, and
very precise questions, I would rather refer you to sa...@intalio.com
for trainings and fast track programs.

Best Regards,

Nico

> --
> You received this message because you are subscribed to the Google Groups "tempo-dev" group.
> To post to this group, send email to temp...@googlegroups.com.
> To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tempo-dev?hl=en.
>
>

Harald

unread,
Feb 19, 2010, 8:53:49 AM2/19/10
to tempo-dev
Hi Nico,

in my context I have a concrete development question.
We need a posibility inside a "chained execution" workflow to go back
to each completed task and modify the task-data and repeat the
following task-steps.

Example of our chained execution:
1) create Task A --> complete Task A --> create Task B --> complete
Task B --> create Task C
2) user wants to go back to Task B and restarts the process from this
step

I think this could be achieved on the database-side of the tempo-
engine using one of the following approaches
A) Clone the processinstance and the tempo-tasks to the task-step I
want to jump back
B) Delete the current task and reopen the previous one

What is your thought about our requirement?

Thanks, Harald

Nicolas Modrzyk

unread,
Feb 20, 2010, 7:24:59 PM2/20/10
to temp...@googlegroups.com
As a reminder note, BPEL does not allow this kind of constructs by
default, and so we have to find workarounds.

Now, it depends how important is that chain flow in your global process.

One solution is to implement the flow logic on the client side, in a
custom form manager.
Then save the current page and the whole set of data in a single task
from the process point of view.
You can then go back and forth the pages as will, and the submit the
data back to the process at the final, and real, task completion.

If all this is really important from a server side process point of
view, you could also have a for-each loop, that create tasks, each one
with a different form URL, and having a counter saved somewhere that
tells you which is the current task. The mapping of the data becomes a
little bit trickier, but your process would then know, which is the
current form that the user is acting upon, and it shows nicely into
your process.

Regards,

Nico

Harald

unread,
Feb 22, 2010, 3:04:02 AM2/22/10
to tempo-dev
Yes I know that this construct is not supported by BPEL.

Our chain flow process is very important and have to be modeled using
BPMN.
So it's not an option for us to implement this logic in the client
side.

We also don't want to see this workaround process-logic inside the
BPMN process model.
Because this would realy blow up our business processes with some kind
of technical process-logic.
So I don't think the for-each loop will a good solution.

Because of all this requirements my thought was to achieve this jump-
back logic
inside the process/workflow engine or directly inside the database on
manipulating the data.

Regards, Harald

On 21 Feb., 01:24, Nicolas Modrzyk <hellon...@gmail.com> wrote:
> As a reminder note, BPEL does not allow this kind of constructs by
> default, and so we have to find workarounds.
>
> Now, it depends how important is that chain flow in your global process.
>
> One solution is to implement the flow logic on the client side, in a
> custom form manager.
> Then save the current page and the whole set of data in a single task
> from the process point of view.
> You can then go back and forth the pages as will, and the submit the
> data back to the process at the final, and real, task completion.
>
> If all this is really important from a server side process point of
> view, you could also have a for-each loop, that create tasks, each one
> with a different form URL, and having a counter saved somewhere that
> tells you which is the current task. The mapping of the data becomes a
> little bit trickier, but your process would then know, which is the
> current form that the user is acting upon, and it shows nicely into
> your process.
>
> Regards,
>
> Nico
>

Reply all
Reply to author
Forward
0 new messages