RSVZ - B2B Fluxen
RSVZ Architecture
Historiek wijzigingen
Datum
18/1/2008
29/1/2008
22/10/2008
3/12/2008
5/12/2008
Omschrijving
Initiële versie
Eerste review
Versie voor 1e technische werkgroep
Versie voor 2e technische werkgroep
Translation into English
Bug fix – Affiliation example Race Condition
Wijziging uitgevoerd door
Dirk Vaneynde
Ronny Martens
Dirk Vaneynde
Dirk Vaneynde
Dirk Vaneynde
Distributielijst
Ontvanger
Eigenaar
Versienummer
Versie van
Afgedrukt op
Naam bestand
Dirk Vaneynde/Cegeka
11
28/07/2017 21:51
28/07/2017 21:51
RSVZ - B2B Fluxen.docx
Niets uit deze uitgave mag worden verveelvoudigd, openbaar gemaakt, overgeschreven, opgeslagen in een automatisch gegevensbestand, of vertaald
in enige menselijke of computertaal, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, magnetisch, optisch, chemisch, met de hand of
op enige andere wijze, zonder uitdrukkelijke schriftelijke toestemming van Cegeka N.V.
Cegeka N.V. behoudt zich het recht voor om de informatie in dit document te wijzigen of te herzien zonder voorafgaande kennisgeving.
 Cegeka 2007-2008
RSVZ - B2B Fluxen
RSVZ Architecture
Inhoudstafel
1.
PURPOSE OF THIS DOCUMENT ........................................................................................ 3
2.
CONCEPT .......................................................................................................................... 4
3.
EXAMPLES OF FLUXES...................................................................................................... 6
3.1
3.2
3.3
4.
AFFILIATION – FIRST SIMPLE EXAMPLE............................................................................................ 6
BASIC BULK TRANSFER EXAMPLE .................................................................................................. 9
AFFILIATION – EXAMPLE WITH RACE CONDITIONS ........................................................................... 12
FLUX MODEL .................................................................................................................. 14
4.1
BASIS INTERACTIE-PATRONEN ................................................................................................... 14
4.2
COMPOSITION OF INTERACTIONS ................................................................................................ 17
4.3
FLUX SYNCHRONISATION ALGORITHM – OUT-OF-SYNC DETECTION ..................................................... 19
4.1.1
4.1.2
4.1.3
OW Interaction ............................................................................................................ 14
RR Interaction .............................................................................................................. 15
Bulk-OW Interaction ..................................................................................................... 15
4.2.1
Duplex ......................................................................................................................... 17
5.
FLUX METAMODEL ......................................................................................................... 20
6.
HISTORY ........................................................................................................................ 22
6.1
OVER SYNCHRONISATIE, OPERATIENAMEN, TRIGGERS, SOURCE STATE ................................................... 22
28/07/2017
Cegeka
blz. 2 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
1. Purpose of this Document
De flow of messages between two or more communicating parties can be very complex. For easy and
correct automation of these exchanges a solid and consistent definition of these fluxes is essential.
An additional problem is that communication channesl are inherently unreliable, so that messages may be
lost or that messages may arrive out-of-order. We must be able to at least detect such problems
automatically.
This document first describes our solution conceptually, a solution that we have called a flux, where we
give some example scenarios. Then we describe in detail how fluxes should be read or constructed.
Finally a chapter ‘History’ describes some issues, what option has been retained and why.
28/07/2017
Cegeka
blz. 3 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
2. Concept
The solution we propose is loosely based on protocol state machines, and also on the Web Service
standaard WS-CDL, http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/.
To make it a bit more concrete you can replace in the figure below “Company A” by NISSE (RSVZINASTI) and “Company B” by SIF xyz, or vice versa. The WS-CDL “Choreography” then defines and
describes for a given functionality, say Affiliation, all possible interactions that may occur between SIF
and NISSE to complete an Affiliation. In the context of web services these interactions are of course web
service operations, in other words soap messages.
Both a SIF and the NISSE have internal processes, which may or may not use an underlying process
engine. In the example Company A uses a WS-BPEL process engine, whereas Company B just uses Java
code. Both have to comply with the Choreagraphy, besides other requirements proper to the owning
company, A or B. As an example, the NISSE process for Affiliation is quite different from that of a SIF,
and contains specific workflow actions in case an affiliation needs to be investigated by the REP services
28/07/2017
Cegeka
blz. 4 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
– functionality that is of course absent on the SIF side. Sif’s may have other functionality in the process,
such as reading an e-ID card.
A choreografie defines how two parties communicate – which messages, in what possible sequences –
in the context of some specific business functionality that encompasses multiple companies. Internally at
each company there are company-specific processes that use the messages defined by the
choreografie, data from local databases, input from users etc. to help achieve the same business
functionality. So the choreography is just one of the specifications that a process must comply with.
Unfortunately the WS-CDL standard has some serious drawbacks:
1. WS-CDL is not supported or implemented by any of the major software vendors.
2. WS-CDL is intended to be supported by tools, e.g. with a GUI to define these choreographies,
and is very flexible – which makes it a very complex standard, too difficult to be used without
such tools.
Therefore we’ve chosen not to use WS-CDL, but a simpler approach based on protocol state engines with
the same base concepts.
The next chapter introduces the flux concept ‘by example’.
28/07/2017
Cegeka
blz. 5 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
3. Examples of Fluxes
The WS-CDL choreographies can also be seen as peer-to-peer protocol definitions. These offer fewer
possibilities than WS-CDL (e.g. passing a ‘channel’ to a party) but we do not really need these features.
Een choreografie kan ook gezien worden als een peer-to-peer protocol beschrijving.
Protocol definitions typically use state engines. In this chapter we give a number of examples of protocols
and their associated state engines.
3.1 Affiliation – first simple example
As a first example we choose Affiliation. Here an Affiliation starts with a request “InvestigateNew” issued
by a SIF. Next there are four alternative possibilities, depicted in the sequence diagram below.
These four possible message exhanges correspond with two – related – state engines, one for SIF and
one for NISSE. The figure below is the state engine for SIF.
28/07/2017
Cegeka
blz. 6 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
stm Aansluiting1
sif_Requesting
sif_Suspended
Suspend
+
do / InvestigateNew
sif_Initial
Accept
Refuse
Accept
sif_Accepted
Refuse
sif_Refused
Transitions with a name, e.g. “Suspend”, are received messages, or web service operations that a SIF
must provide and implement.
The “do/” actions inside a state, e.g. “InvestigateNew” inside state sif_Requesting, are messages that are
sent while in this state. In web service parlance, these are calls of web service operations provided by
NISSE.
In this example all operations are One-Way (OW). Later examples will give other web service operation
types. Note that fluxes work with conceptual operation types; the difference between POW or ROW is not
important at this level.
In the SIF state engine there is one transition without a name, between the Initial and Requesting state.
In typical cases there will be multiple such transitions. These transitions are taken dependent on internal
business logic, that is outside the scope of the protocol or flux. In this example a SIF employee would ask
for a new Affiliation using a menu option in a GUI application, which would trigger the transition from
initial (=creation of a flux instance) to Requesting.
For Nisse we have a ‘mirror’ state engine shown below.
stm Aansluiting1
nisse_Suspended
nisse_Requesting
InvestigateNew
+
do / Suspend
nisse_Initial
nisse_Accepted
+
do / Accept
nisse_Refused
+
do / Refuse
The state names and operation names in both state engines are the same, the only difference being that
operation names appear in other places. The reason for this difference is that the sending party is
sending because it already is in a state that the other party will transition to when it receives this
message.
Let’s walk through the sequence diagram scenario to clarify this.
28/07/2017
Cegeka
blz. 7 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
Some SIF takes the initiative to start an Affiliation. Through some web application a SIF employee
requests a New Affiliation, and the SIF state engine arrives in state Requesting. Within that state a
message InvestigateNew() is sent to Nisse.
Nisse receives the InvestigateNew() message which triggers a new Affiliation state engine and
immediately transitions into Requesting as well. Note that both state engines are synchronized, i.e. in
the same state.
Within Requesting state Nisse will start some automatic checks, which leads either to an immediate
decision – Accepted or Refused – or human intervention by the REP service is needed in which case we
go into Suspended state for some hours or days.
Suppose that Nisse can accept this affiliation request automatically and thus immediately. The Nisse state
engine transitions to Accepted state – which implies that the requesting person is marked officially (!) as
a Self-Employed in ‘Repertorium of Self Employed’, attestations are sent to other institutions etc. Only
thereafter (!) an Accept() message is sent to the requesting Sif.
At reception of this Accept() message the Sif is still in state Requesting, causing a transition into
Accepted. Again state engines are synchronized.
This synchronization allows for automatic detection of wrong operations being sent. For example, if a Sif
would now receive a Refuse() message from Nisse within the same Affiliation flux – clearly the
consequence of a bug at Nisse – then this would be automatically detected since there is no transition
named ‘Refuse()’ from state Accepted.
In summary:
1. Fluxes - choreographies or protocols – between two parties are modelled using two closely
related state engines.
2. It is clear for all communicating parties which messages may be sent when, and which messages
they may receive at any given time (state).
3. Concrete flux instances, e.g. an Affiliation of Person x, leads to two state engine instances, that
are traversed in close synchronisation. Automatic detection of ‘the wrong message at the wrong
time’ is perfectly possible.
Final thought: A flux must be the consequence of a business process, not define the business process.
But a flux proves that a business process is automateable.
28/07/2017
Cegeka
blz. 8 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
3.2 Basic Bulk Transfer Example
Below is a figure with a typical scenario of a Bulk Transfer.
It works like this:
 A SIF sends 1,2 or more Careers to NISSE, each quarter
 Each message (operation) carries a Block element, containing the sequence number of the last
block and the sequence number of the current block. In other words, up-front the total number
of messages must be known. The last block is then identified by the current sequence number
being equal to the last one.
 In this process the SIF requests an official ‘Receipt’ – for example to be able to prove later on
that all data was provided in time. Note that this Receipt should bear a digital signature to be
really useful.
 Somewhat later, perhaps after processing overnight, a rapport is sent back to SIF indicating
which careers contained business errors.
The corresponding flux state machines are described in the next figure. It adds an optional Cancel()
operation, not shown above.
28/07/2017
Cegeka
blz. 9 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
stm UploadCareer
SIF
NISSE
Initial
Initial
Cancelled
Cancelled
+
ow_UploadCareer
do / ow_Cancel
Cancel
TransferData
TransferData
ow_UploadCareer
+
do / ow_UploadCareer
[Block.SequenceNbr == Block.LastNbr]
[Block.SequenceNbr == Block.LastNbr]
Uploaded
Uploaded
ow_ProcessReceipt
Receipt
Receipt
+
do / ow_ProcessReceipt
ow_ProcessReport
Report
Report
+
do / ow_ProcessReport
Legend:
 All states are identical at Nisse and Sif side.
 A state transition with an event starting with “ow_” is a one way message received by that party,
either Sif or Nisse.
 A “do” action within a state corresponds to the sending of a message to the other side.
Let’s show how our scenario would work with the above state engine. The Sif column are the state
transitition and current state and of the Sif side, the Nisse column is the same for the Nisse side. In the
middle is the message (operation) travelling in  sense or  sense. Note that ‘bulk’ messages contain
additional IsLast and SequenceNumber data in the Block structure, as explained in the B2B Guidelines.
Each message also contains the current state of the sending party.
Nr
1
2
3
4
Sif
InitialTransferData
Message
 ow_UploadCareer
Current State = TransferData
IsLast = false, SeqNbr = 0
Initial  TransferData
TransferData 
TransferData
 ow_UploadCareer
Current State = TransferData
IsLast = false, SeqNbr = 1
5
TransferData 
TransferData
6
7
Nisse
TransferData 
TransferData
8
28/07/2017
 ow_UploadCareer
Cegeka
blz. 10 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
Current State = TransferData
IsLast = true, SeqNbr = 2
9
10
11
12
TransferData  Uploaded
13
14
15
Uploaded  Receipt
16
sif_Receipt  sif_Report
TransferData  Uploaded
Uploaded  Receipt
 ow_ProcessReceipt
Current State = Receipt
Receipt  Report
 ow_ProcessReport
Current State = Report
Both partners can check that their view of the ongoing process, i.e. their state engine, is consistent with
the other party. A receiving party must check that it can do the transition identified by the operation
name, and that the target state equals the current state in the message.
The above table does not suggest that the sending side waits for the receiving side to accomplish the
state transition. The next scenario is valid as well.
Nr Sif
Message
Nisse
InitialTransferData
1
 ow_UploadCareer
2
Current State = TransferData
IsLast = false, SeqNbr = 0
TransferData 
3
TransferData
 ow_UploadCareer
4
Current State = TransferData
IsLast = false, SeqNbr = 1
Initial  TransferData
5
TransferData 
6
TransferData
...
28/07/2017
Cegeka
blz. 11 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
3.3 Affiliation – example with Race Conditions
A more realistic Affiliation is when we add error handling – if the request contains syntax errors – and the
option that a Sif may Cancel an Affiliation when it is investigated by the REP services, i.e. in Suspended
state.
The full state engine at Sif side:
stm Sif Affiliation
Cancelling
ErrorInRequest
Cancelled
+
do / Cancel
ConsideredNonExistant
[need-to-stop]
CorrectInput
Requesting
Suspended
Suspend
+
do / InvestigateNew
Initial
Refuse
Refuse
Accept
Accept
Accept
Refuse
Accepted
Refused
The full state engine at Nisse side:
stm Nisse Affiliation
ErrorInRequest
+
ConsideredNonExistant
Cancelling
+
do / CorrectInput
do / Cancelled
Cancel
[error in input]
Suspended
Requesting
InvestigateNew
+
do / Suspend
Initial
Final
Accepted
+
Cancel
do / Accept
Refused
+
do / Refuse
History
A Sif can only send a Cancel() if it is in state Suspended – which has been a business decision before.
First the Sif’s state engine goes into Cancelling state and then the Sif sends a Cancel() operation.
At that moment Nisse can be in one of three states:
28/07/2017
Cegeka
blz. 12 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
1. Suspended
2. Accepted, which just happened, and the Accept() is not yet sent or already sent but not
yet handled by Sif
3. Refused, which just happened, and the Refuse() is not yet sent or already sent but not
yet handled by Sif
In case 1 Nisse immediately goes into state Cancelling, cancels the Affiliation internally and sends a
confirmation to the Sif through a Cancelled() message.
The second and third case are quite rare but possible cases called a “race condition”: the two parties
each send a message at about the same time and these messages cross each other. “About the same
time” is actually the period it takes between sending a message and processing it on the other side –
which on the Internet or other big networks may take some time, from a few milliseconds to seconds.
When Nisse receives a Cancel in case 2 or 3 it will do nothing, as shown by the self-transition Cancel on
superstate Final. So even if Nisse receives a Cancel() before it sent the Accept() or Refuse() operations, it
will just continue processing and send the Accept() or Refuse().
At the Sif side in case 2 or 3 this Accept() or Refuse() is received leading to an Accepted or Refused final
state respectively, indicating implicitely to Sif that the Cancel failed.
Note: It is important to understand the UML ‘language’ on state engines. Specifically, transitions are
atomic, as if they do not take time, unlike states. Also a flux instance is always in exactly one state, never
in multiple states.
28/07/2017
Cegeka
blz. 13 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
4. Flux Model
4.1 Basis Interactie-Patronen
At the web service level we conceptually have three types of operations: Request-Reply (RR), One-Way
(OW) en Bulk-One-Way (Bulk-OW). The figure below shows these three conceptual building blocks.
Further details on these conceptual operation types and their concrete realizations (Pseudo-One-Way,
Reliable One Way) check out the RSVZ - B2B Guidelines.docx document. However note that for Fluxes
the concrete operation type is not important.
The operation types have a 1-to-1 mapping on flux state engine building blocks, which we define in this
chapter. Party A and B are of course Nisse and Sif, or Sif and Nisse.
4.1.1 OW Interaction
stm One Way
Party A
Party B
s0
s0
some_event
ow_operation
s1
+
do / ow_operation
s1
Sequence:
1. Initially both parties are in state s0.
2. Because of an internal event Party A transitions into state s1. Here A sends an ow_operation() to
B.
3. Party B receives ow_operation() and transitions into s1.
4. Both operations are back in sync, state s1.
28/07/2017
Cegeka
blz. 14 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
4.1.2 RR Interaction
stm Request Reply
Party A
+
Party B
s0
s0
some_event
rr_operation
s1
s1
do / rr_operation
+
do / result
Sequence:
1. Initially both parties are in state s0.
2. Because of an internal event Party A transitions into state s1. Here A sends an rr_operation() to
B. Party A remains blocked and waiting in state s1, at least until a reply (“result”) is received.
3. Party B receives rr_operation() and transitions into s1. In this state B sends the answer (“result”)
back to A.
4. Both operations are back in sync, state s1.
Note that the reply “result” is not a transition at party A!
In s1 at Party B there can be multiple transitions arriving, through multiple received operations. These
oparations must all be RR en the reply must be the same “result” structure for all. Technically this means
that the wsdl <output> element must be the same vor all of these RR operations.
4.1.3 Bulk-OW Interaction
stm Bulk One Way
Party A
Party B
s0
s0
bulk_ow_operation
s1
s1
bulk_ow_operation
+
do / bulk_ow_operation+
[Block.LastSeqNr ==
Block.CurrentSeqNr]
[Block.LastSeqNr ==
Block.CurrentSeqNr]
s2
s2
Volgorde:
1. Initially both parties are in state s0.
28/07/2017
Cegeka
blz. 15 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
2. Because of an internal event Party A transitions into state s1. Here A sends one or more
bulk_ow_opearation() messages to party B. Party A remains in state s1 until all blocks have been
sent.
3. Party B transitions to state s1 at the arrival of the first bulk_ow_operation(), and remains there
on each subsequent received bulk_ow_operation() message.
4. After having sent the last bulk_ow_operation() message A transitions to s2.
5. After having received the last bulk_ow_operation() message B transitions to s2.
The separate state s2 is not strictly necessary. It is handy to explicitely indicate that a bulk transfer is
going on or has ended if you use some web application to visualize the fluxes for operational purposes.
28/07/2017
Cegeka
blz. 16 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
4.2 Composition of Interactions
4.2.1 Duplex
In this case both parties may send or receive a message when in the same state. The figure below shows
three possible situations.
sd Complex1
P1
alt A-B
P2
A()
B()
alt A-C
A()
C()
alt Race Condition
A()
B()
C()
After party P1 has sent operation A() to P2 we have three options:
1. P2 sends B() to P1
2. P1 sends C() to P2
3. P1 and P2 send at about “the same period” operations C() en B() respectively – a race
condition.
For more details on race conditions see “Affiliation – example with Race Conditions” at page 12.
In case of a possible race condition one state must be chosen as the “winning” state, and this is reflected
in the design of the flux. Here we choose that C() takes precedence over B(). The flux state engines then
are like shown below.
28/07/2017
Cegeka
blz. 17 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
stm Complex1
P1
P2
s0
s0
A
s1
+
s1
do / A
B
C
s2
s3
s2
s3
C
+
do / C
+
do / B
B
There is one possible problem with the above solution: when is P2 sure that s2 is definitive, and no C()
operations must be expected? This we can solve by adding one extra state and operation, s4 and BFinal() shown below.
stm Complex1
P1
P2
s0
s0
A
s1
+
s1
do / A
B
C
s2
s3
s2
s3
C
+
do / C
+
do / B
B-Final
B
s4
+
s4
do / B-Final
This state chart has been used for solving the race condition in Affiliation discussed earlier.
28/07/2017
Cegeka
blz. 18 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
4.3 Flux Synchronisation Algorithm – Out-Of-Sync Detection
Out-of-Sync detection is an algorithm to automatically detect that two communicating parties involved in
the same flux instance no longer have their state engines synchronized.
To understand this there is one piece missing, explained in RSVZ - B2B Guidelines.docx: the
“SourceState” element in the ApplHeader.FluxDescriptor included in each web service operation message
that participates in a Flux. It holds the “current state” when sending the operation of the sending party.
Here is the algorithm.
Support party A is in state “s1” and calls party B with operation “op1”, and op1.sourceState==s1.
Party B checks the following:
 The current state at B must have an outgoing transition named “op1”.
 The target state of that transition must be equal to the SourceState element in “op1”, i.e. “s1”.
If these checks fail, party B sends a “FluxOutOfSync” system error:
 If “op1” is a RR operation an FluxOutOfSync fault is sent back.
 If “op1” is a OW operation a separate {General}FluxOutOfSync one-way operation is sent.
There is no automateable and generic solution to out-of-sync problems; they can only be detected
automatically. On detection manual intervention is necessary. In practice we have these options:
1. The problem is investigated and solved, and the state engines are ‘set back’ so that they are
synchronized again
2. The complete flux and attached processes are undone.
3. The flux and attached processes go into a special end-condition.
How this problem is solved needs to be investigated for each individual business process.
28/07/2017
Cegeka
blz. 19 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
5. Flux Metamodel
The schema below shows the flux metamodel, with 3 parts:
 “Definitie”, top part: the definitions of a flux, and the two corresponding state engines – one per
communicating party. Today this is only Nisse and Sif, hence a multiplicity of 1..2.
 “Runtime” – FluxInstance: each communicating party holds privately a FluxInstance object, per
on-going flux exchange. With two parties communicating there als always 2 such instances.
 “Runtime” – Operation: a message or operation of that flux travelling between communicating
parties has references to the FluxInstance via the FluxDescriptor block in the Message.
class FluxMetamodel
Definitie
TransitionDef
FluxDef
+
«KEY»
+ name: String
+ version: int
name: String 0..*
WsOperation
+to
0..1
1..2
FluxStateEngine
StateDef
1..*
+beginState
0..1
+localDefinition
0..1
+
0..1
1
0..1
1
+from
0..1
name: String
0..*
1
+currentState
Runtime
B2B::OperationB2B
FluxInstance
-
privateProcessId: int
«KEY»
+ fluxId: string
+ initiator: PartyType
constraints
1
B2B::FluxDescriptor
+
+
-
B2B::ApplHeader
initiator: PartyType
fluxid: string
0..1
sourceState: string
fluxDefinition: FluxDef
There are some interesting constraints:
1. A FluxInstance refers to exactly one FluxStateEngine, corresponding to exactly one FluxDef. It also
refers to exactly one state, its “current” state, that must of course be part of the same
FluxStateEngine instance.
Finally, it might refer to a process id via the privateProcessId attribute, or some fluxinstance-specific
information in a database table.
2. Some TransitionDef instances, and some StateDef instances have a message/operation attached.
a. There are a number of constraints that follow from the rest of this document. Perhaps some
day there is time to describe these formally.
b. These operations are of course part of a WSDL description.
3. A web service operation has one important part in this respect, the <input> message, that carries
the ApplHeader. Because of DocumentLiteralWrapped the <input> message has the same name as
the Operation1. When participating in a Flux, the FluxDescriptor is mandatory.
a. FluxDescriptor.initiator == FluxInstance.initiator
1
More correctly, the first element of the soap Body has the same name as the Operation – which is also defined in that way in the
WSDL.
28/07/2017
Cegeka
blz. 20 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
b. FluxDescriptor.fluxid == FluxInstance.fluxid
c. FluxDescriptor.fluxDef == FluxInstance.FluxStateEngine.FluxDef
d. FluxDescriptor.currentState: see earlier in this document
Below is a concrete scenario of the Affiliation described earlier.
SIF “000” starts a new Affiliation, according to Affiliation Flux V2 – represented by the yellow boxes
below. So it creates a local FluxInstance, with local and global flux id “12345”. Then it forwards to state
“Requesting” and sends a message InvestigateNew with MessageID “15681” to NISSE.
sd Sif
Affiliation_V2 :
FluxDef
Sif :FluxStateEngine
beginstate
initial :StateDef
:TransitionDef
Requesting :StateDef
Inv estigateNew :
WsOperation
12354 :FluxInstance
initiator = Sif000
fluxId=12354
currentState=Requesting
+sentMessage
:ApplHeader
Inv estigateNew _15681 :
OperationB2B
:FluxDescriptor
initiator = Sif000
fluxId=12354
currentstate=Requesting
fluxDef=Affiliation V2
NISSE receives the message and will also create a FluxInstance. Internally this FluxInstance has a
number “a87ef”, but globally it has the same fluxId “12354”. After processing the message the current
state becomes “Requesting” at the NISSE side as well.
sd Nisse
Nisse :
FluxStateEngine
initial :StateDef
:TransitionDef
Requesting :StateDef
Affiliation_V2 :
FluxDef
Inv estigateNew :
WsOperation
a87ef :FluxInstance
initiator = Sif000
fluxId=12354
currentState=Requesting
+ReceivedMessage
Inv estigateNew _15681 :
OperationB2B
:ApplHeader
:FluxDescriptor
initiator = Sif000
fluxId=12354
currentstate=Requesting
fluxDef=Affiliation V2
And so on…
28/07/2017
Cegeka
blz. 21 van 22
RSVZ - B2B Fluxen
RSVZ Architecture
6. History
Here we’ve put all historical issues, discussions etc. that have come to a decision.
6.1 Over synchronisatie, operatienamen, triggers, source state
Uitgangspunten:
- We willen web service operaties herbruiken in meerdere fluxen. Bijvoorbeeld LegalInfo vragen
worden in meerdere processen gebruikt.
- We willen alle state-desynchronisaties tussen twee partijen kunnen detecteren.
- Eenzelfde operatie kan soms een flux starten (trigger) of een gewone state-transition
veroorzaken tussen twee gewone toestanden. Conform vorige punt moet het verschil kunnen
gedetecteerd worden.
Vragen.
1. opA kan zowel flux A triggeren als een state-transition veroorzaken. Is dat toegelaten?
2. opA kan zowel flux A als flux B triggeren. Is dat toegelaten?
3. zowel opA als opB kunnen flux A triggeren. Is dat toegelaten?
4. operatie opC kan binnen één flux vanuit meerdere toestanden dezelfde eindtoestand bereiken. Is
dat toegelaten?
5. operatie opC kan binnen één flux verschillende state-transitions veroorzaken, waarbij alle states
verschillend zijn. Is dat toegelaten?
Mogelijke oplossingen en wat is toegelaten.
-
Elke operatie heeft een FluxDescriptor, met de flux definitie en versie.
Dit lost op: 2, ook 3.
De ApplHeader zou de ‘huidige toestand’ kunnen bevatten, zoals gekend door de verzender.
(De protocol synchronisatie-toestanden moeten dan zeker in de state engines van de twee
partijen dezelfde naam hebben – dat is nu een impliciete regel, moet expliciet worden.)
Dit lost op: 4, 1 (bij starttoestand is source-state ‘nil’), 5.
Beslissing:
 Applheader moet extra “Source Toestand” en hierrond moet expliciete regel toegevoegd.
28/07/2017
Cegeka
blz. 22 van 22