Thank you very much for these hints, do you have any site or hint about how you've learned BPEL? I'm newbie and don't know how to make more complex things =/ sorry for the spam and thanks once more...
> Date: Tue, 10 May 2011 11:37:40 -0400 > From: [email protected] > To: [email protected] > Subject: Re: Question about using BPEL > > Yep. For this use-case though, I think a single process would work just fine. > @Samuel, have a look at the <forEach> with parallel="yes" > > Cheers, > Bob > > _______________________________________ > Robert ("Bob") Brodt > Senior Software Engineer, JBoss Riftsaw > JBoss by Red Hat > > ----- Original Message ----- > > I'd like to second that. This is also a nice example for using two > > partnerlinks. One for the bi-lateral connection between party host and > > process, and another one for the connection between process and > > potential guests. > > > > Anyhow, you also might think of splitting the process into a > > party-host-process and a invitation-process. The latter is exactly > > like > > the process you have described, the first is in charge to spawn an > > instance of the first process for each guest and then collect the > > results. This is a "request-with-referral" SIP > > (http://math.ut.ee/~dumas/ServiceInteractionPatterns/Animation-Request-with-Referral.html) > > > > I think the important thing is to overcome the procedural thinking. > > Instead of having a single process instance that takes care of > > everything, it is better to have a process instance for each guest so > > that a process instance is directly connected to the state of an > > invitation of a guest. > > > > Tammo > > > > On 10.05.2011 16:27, Bob Brodt wrote: > > > 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 > > >>> ------------------------------------------------------------------------------ > > > > -- > > Tammo van Lessen - http://www.taval.de
