RE: [ebxml-bp] XSD schema for OASIS BPSS

[Jean-Jacques Dubray <jeanjadu@Attachmate.com>]

Title: Message

Martin:

 

thanks for this great feedback

1) we found that customers do not seem to like to work with the activity diagrams. Even though the ones we put out were accurate, someone else was asked to explain them in more detail and subsequently issued a document with scenarios in that were far more restrictive that they should have been.
[<JJ>] It is clear that moving forward BPSS's control flow needs to be redefined. We might also want to discuss if we want to come up with a corresponding notation. BPMN comes to mind. MEGA had also done a lot of work in this direction.  

2) we find that the state for the Gateway is actually managed in most part by a CRM system. This has two problems,

a) the state models implemented in these systems is often not geared to a neat public/private split and therefore the CRM user feel free to move business objects to states even if these are not supposed to happen. (some of this is because we have automation robots hook of the CRM platform and these need to have states set before they run. Any failures mean that the states have to be reset and this is reflected to the customer!)

b) The steps for the gateway need to be easily identifiable, and this is proving very difficult as we find that development issues creep in that mean that the main headline state is not the only item being monitored and this leads to lots of confusion.

c) the need to be able to cope in the BPSS with transactions being performed through other channels. This is a really major issue. The implications are that the state of one partners system can get out of step legitimately. When modeling this you find that you need to run this transaction over the gateway in reverse. For example, customer places order via phone. This would normally have come over the gateway, so the customers System may now does not reflect this. So instead of order coming from customer, a transaction needs to be enacted that get the customers order back on to their systems.

The consequences of some of this are that we have ended up resorting to simple message in and outbox type transactions on our gateway and using the BPSS only as a documentation tool expressing the ideal process.

With item c) above I think this shoul dbe addressed by the team as without it you are saying that the BPSS only really works in a pure environment which is not very reflective of real life.
[<JJ>] I think that you are giving us a great suggestion here. Let me rephrase it to see if I understood correctly. You are saying that the state of the B2B collaboration could be arbitrarily changed by parties interacting via traditional means. State alignment of the BSI could happen two ways:

a) each party updates its collaboration state (via its internal system) by notifying its BSI

b) one party is in charge of updating its BSI which in turn sends a signal to the other party's BSI to inform it of the state change

c) yet another possibility, which I tend to favor is bring the CRM system (as a web service) in an "end-to-end" collaboration definition.  The BSI could be architected to align a private state automatically.

 JJ-

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: 24 November 2003 05:02
To: BPSS ebXML
Subject: [ebxml-bp] XSD schema for OASIS BPSS

Monica / Dale,

 

Where are we in planning to publish a draft schema?

 

I'd very much like to have a new schema available to the team

internally at least from Kavi - for testing and development purposes.

 

I think this will also help alot with issue diagnosis et al.

 

Thoughts on a plan?  Can we discuss this on today's call?

 

Thanks, DW