Hmm, here's how I would approach this: A BPEL process, being a *service*, needs
to receive some kind of request message to initiate a new process instance.
This could be something like you, as the "party host", sending details of your
party (guest list, date/time, place, etc.) to the process. The process would
then send an invitation to each person on the guest list with an <invoke> on an
email service. The <invoke> would have to define a correlation on the party
invitation message (like the person's first & last name.) Then use a <pick>
with createInstace="yes" to wait for replies. The <onMessage> in the <pick>
would use the same correlation data as the <invoke> on the guest's reply email.
Presumably you would also set a timeout (probably the R.S.V.P. date for the
party) and have an <onAlarm> to handle the "no response" cases. Each email sent
to your guests becomes a separate process instance, with the correlation as a
"handle", so your would have N+1 instances (N=number of guests + 1=the original
invitation request) running concurrently. BPEL is designed for long running
processes, and the runtime (ODE in this case) will persist state information,
so even if the server crashes, your process instances are persisted and will
resume when the server is restarted.
_______________________________________
Robert ("Bob") Brodt
Senior Software Engineer, JBoss Riftsaw
JBoss by Red Hat
----- Original Message -----
> coincidently, I've got one problem similar to this. look, i have this
> case:
> I want to make a more complex test of BPEL, so, I'll make a business
> process that send invitations to my party via email. that's the
> business process:
> 1- send an email with an invitation and ask for answers about who will
> go to the party.2- wait for the answers3- if the answer is 'yes', send
> another email with the party details, else, send an email thanking the
> person for answering.
> the problem for me is that how can i wait for some people answer while
> i have to send the feedback emails... the step 3 depends on the step
> 2, but at the same time one person answer my email and i have to give
> the person a feedback, I have to wait other people answer.
> I don't know if BPEL can do this. for example, if the server shut
> down, would I have to restart all the process(send the invitations and
> wait for all answers again)?
>
>
>
>
>
>
>
>
> > From: [email protected]
> > To: [email protected]
> > Subject: RE: Question about using BPEL
> > Date: Mon, 9 May 2011 15:15:32 +0000
> >
> > As you suggest, parallelism should help. I'm not sure about the
> > dependencies that you're talking about, but correlations could help
> > maybe ?
> >
> > -----Original Message-----
> > From: Samuel Tamassia Martinez
> > [mailto:[email protected]]
> > Sent: lundi 9 mai 2011 17:10
> > To: User ODE
> > Subject: RE: Question about using BPEL
> >
> >
> > this question looks interesting, I haven't thougt of it, does
> > anybody knows about?
> >
> > > From: [email protected]
> > > To: [email protected]
> > > Subject: Question about using BPEL
> > > Date: Fri, 6 May 2011 14:39:32 -0300
> > >
> > >
> > > Hi,
> > > I am creating a process that should be covered by different
> > > clients of mine. Each customer will be in a different step in this
> > > process. I am in doubt about using BPEL to address this question,
> > > since this process would need to perform several steps at the same
> > > time, which to my mind runs away from his purpose.
> > > I'm thinking of using parallelism, but there are dependencies
> > > between the steps that must be performed several times for
> > > different customers.
> > >
> > > Thx a lot!
> > > Bruno Fiusa
> > >
> > > "Just do IT."
> > >
> > >
> > >
> >
> >
> > -
> > -----------------------------------------------------------------------------
> >
> > E-MAIL DISCLAIMER
> >
> > The present message may contain confidential and/or legally
> > privileged information. If you are not the intended addressee and in
> > case of a transmission error, please notify the sender immediately
> > and destroy this E-mail. Disclosure, reproduction or distribution of
> > this document and its possible attachments is strictly forbidden.
> >
> > SPACEBEL denies all liability for incomplete, improper, inaccurate,
> > intercepted, (partly) destroyed, lost and/or belated transmission of
> > the current information given that unencrypted electronic
> > transmission cannot currently be guaranteed to be secure or error
> > free.
> > Upon request or in conformity with formal, contractual agreements,
> > an originally signed hard copy will be sent to you to confirm the
> > information contained in this E-mail.
> >
> > SPACEBEL denies all liability where E-mail is used for private use.
> >
> > SPACEBEL cannot be held responsible for possible viruses that might
> > corrupt this message and/or your computer system.
> > e
> > ------------------------------------------------------------------------------
