OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] Episodical memory requirement


Hi Anders

If I understand you right you have 1 ebBP or BPSS which describes those
3 transactions.

So I understand, that at runtime you have 2 instances of those ebBP's
running in a ebXML Business Service Interface (BSI).

o One for business with party X and
o One for business with party X.

So in my understanding the BSI exectues or monitors those 2 ebBP
instances. The BSI unpacks payload (PO, POC and invoice)  of the ebXML
messages and forwards the payload documents to the backend application
(ERP systems).

Do you need a reference on the ebXML message level or the payload
dcoument level?

So if the payload references other payload documents then its part of
the backend system to handle that.

It should be obvious, that in a ebBP if you send a purchase order
confirmation, that is based on the purchase order which happens in the
same ebBP. I think ebXML messages (assuming that the ebXML messages have
the same name as the payload documents) include references to the
previous message ... so you should be able to trace the purchase order
back from a purchase order confirmation (by the persistent/archiving
ebXML BSI, ebXML Messaging Service Handler).

So per ebBP instance, you almost have 2 purchase orders: 1 ebXML
purchase order document which holds ebXML messaging data plus a purchase
order payload document. In the ebXML realm you can retrieve the ebXML
purchase order document (and retrieve the purchase order payload
document) but in the backend application you only have the purchase
order payload document.

So concerning memory ... I would say the backend application, ebXML BSI
and ebXML Messaging Service Handler are persistent and archive
transactions. I would guess they handle persistence by a database and do
not keep it in memory...

Sacha

On Thu, 2004-07-08 at 09:28 -0400, David RR Webber wrote:
> Anders,
> 
> I believe this is the purpose of the JOIN.
> 
> To prevent something completing before all necessary 
> prior steps have completed.
> 
> See the JPG of the model and activity flow here - that 
> implements exactly the example you provide (I believe).
> 
>  http://drrw.net/visualscripts/#ebxml 
> 
> Thanks, DW.
> 
> ----- Original Message ----- 
> From: "Anders W. Tell" <anderst@toolsmiths.se>
> To: <ebxml-bp@lists.oasis-open.org>
> Sent: Tuesday, June 08, 2004 3:31 AM
> Subject: [ebxml-bp] Episodical memory requirement
> 
> 
> > Dear Team
> > 
> > I was asked to provide a use case that show the need for Memory in 
> > ebBP,ie. requirements for keeping information between exchanges of data 
> > messages.
> > 
> > Use case:
> > 3 transactions are defined in an ebBP or BPSS: Order{PO}, 
> > OrderAcceptance{POC}, RequestForPayment{Invoice}.
> > 
> > Two partners enact two business-dialogs in parallell
> > BD1:  PO1 with goods for 1M Euro -> Order is accepted with POC1
> > BD2:  PO2 with goods for 100 Euro -> Order is accepted with POC2
> > 
> > In order to make sure that the Invoice sent in B.Dialog BD1 is in any 
> > way is related to POrder1 something must be remembered about PO1 
> > otherwise it is possible to send an invoice related to PO2 in the 
> > B.Dialog1 and thus complete BD1 leaving BD2 behind.
> > 
> > hope this  helps
> > Thanks
> > /anders
> > 
> > -- 
> > /////////////////////////////////////
> > / Business Collaboration Toolsmiths /
> > / website: <www.toolsmiths.se>      /
> > / email: <anderst@toolsmiths.se>    /
> > / phone:  +46 8 562 262 30          /
> > / mobile: +46 70 546 66 03          /
> > /////////////////////////////////////
> > 
> > 
> > 
> > 

This is a digitally signed message part



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]