B2B Processflow

Download Report

Transcript B2B Processflow

Process Flow for TSS - Supplier
This document describes the process and
interdialogue rules in the NeBI interface between TSS
and subcontractors.
Security: Public
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 1
Document History
2003-12-11
Ove Fritz
C
2004-02-23
Lars Abrell
D
2005-10-11
Per Rudal
PE1
RenegOrder init av FNS uppdaterad, ny slide ExecuteOrder med OEA
justerade format (master slide), puts
2005-10-11
Per Rudal
PE2
FNS ändrat till Supplier, puts av slide Villkor
2005-11-04
Per Rudal
PE3
Nya slides Dialogöversikt o Affärsregler. ExecuteOrder med OEA borttagen tills vidare.
2005-11-04
Hans Guste
PE3_1
Rubrik Affärsregler ändrad till Interdialogregler, Approved tillagt sid 1
2005-11-18
Anders Hultin
PE3_2
Interdialogregler kommenterade efter internt Relacommöte
2005-12-07
Per Rudal
PE4
Interdialogreglerna uppdaterade efter e-gs-forum 29/11.
CancelOrder: ruta 6b, “ESN2”, är ny.
RenegOrderBySup: ruta 12, “manuell hantering” är borttagen.
2005-12-23
Per Rudal
PE5
Interdialogreglerna uppdaterade efter e-gs-forum 14/12 (h-regel 4, tillägg 4-6)
Nya slides: 2 Transaktionsmönster, 3 Omsändning o larm
2006-01-16
Per Rudal
PE6
Uppdatering efter e-gs-forum 11/1: slide 2, Transaktionsmönster; slide 3, Omsändning, heart-beat o larm; slide 11, Inderdialogregler 2, punkt 2, 3, 6.
2006-06-20
Per Rudal
E
Version för gränssnittsdokument J.
PE7 utgår. Röd reservationstext i Interdialogreglerna borttagen.
2006-06-20
Per Rudal
F
Version för gränssnittsdokument K.
Ny slide 9, RenegotiateOrder initierad av Supplier alt B.
2006-06-20
Per Rudal
PG1
Dialog för leveransgodkännande, “ExecuteOrder med OEA” återinförd (jmfr PE1 o PE2 ovan)
2006-10-20
Per Rudal
PG2
slide 3: Omsändning http-nivå Telia: 3*120s -> 7*4min
slide 4 Dialogöversikt + slide 9, Reneg Supplier alt B + slide 11, EO m levgodk: version 3.1 -> 4.0
2006-11-08
Per Rudal
G
Version för gränssnittsdokument L
2006-12-01
Per Rudal
PH1
Version för gränssnittsdokument M
Ny layout. Ny slide 6, NegotiateOrder med förhandling + slide 4, Dialogöversikt uppdaterad
2007-01-19
Hans Guste, PeRu PH2
Translation to English. New doc name “NeBi_proc_TSS-Supplier PH2”. New slide Dialogue rules. Inter-dialogue rules updated.
2007-01-31
Per Rudal
H
Process version for NeBI_doc_TSS-Supplier_M.doc (no changes except for version and date)
2007-02-15
Per Rudal
PI1
Process version for NeBI_doc_TSS-Supplier_PN1.doc: added dialogue InvoiceDetail
2007-05-10
Per Rudal
PI2
slide 14, InvoiceDetail: InvoiceDetailPart rules
2007-09-19
Per Rudal
PI3
New slide 15, RequestRequisite (+ slide 5, Dialogue overview updated), slide 3, Transaction Pattern adjusted for RR
2007-09-28
Per Rudal
I
Process version for doc spec N. Slide RequestRequisite corrected
2007-11-26
Per Rudal
PJ1
Process version for doc spec PO1. Added slide 13+15, dialogues ExecuteOrder_3.1 + 4.1
2007-12-20
Per Rudal
J
Process version for doc spec O. Slightly adjusted are slides 13, 15 and 20 rule 2..
2008-10-01
Per Rudal
J2
New slide 16: ExecuteOrder w partial execution + delivery acc
Improved slides: slides 12-15, EO variants: statuses; slide 21: Inter-dialogue Rules 2
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 2
Transaction Pattern
NeBI
Responder
Initiator
1.
Trans A
2. Request
(dialog + trans)
3. ebMS service + action
(=dialog + trans)
6. Ack / Error
4. ebMS
header
validation
5. MSHack / Error
7.
8. Request
(dialog + trans)
12. ebMS service + action
(=dialog + trans)
14. MSHack / Error
17.
16. Request
(dialog + trans)
Application
10.
11. Request
(dialog + trans)
15. Ack / Error
Trans B
13. ebMS
header
validation
B2B
B2B
Dialog X
Application
9.
The dialogue above is an example. The internal flow of a party (B2B to/from App) including function names etc are determined entirely by the party itself.
Dialogue X consists of two transactions: trans A, inititiated by the Initiator; and trans B, initiated by the Responder.
The common public NeBI-interface (B2B to B2B, pink above) shows the NeBI transaction pattern which is valid for all NeBI
transactions (but RequisiteRequest). A NeBI transaction (each pink box above) consists of:
a) A transaction request, which is an http-request holding one ebMS-message including a business document, e g an Order
b) A transaction reply, which is a new separate http-request holding one ebMS-message containing an MSH-ack or Error
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 3
Resending, Heart-beat and Alarms Sönnico, Ericsson?
This slide describes the resending pattern, heart-beats and alarms for (missing) events in the NeBI interface.
All values are configurable. Current values are indicated.
1.
Resending on http-level
If http-return is not received for an http-request, then:
2.
•
TSS
will resend the http-request every 4min 7times
•
Eltel
will resend the http-request every 120s during 24h
Resending on transaction level
If MSH-ack (Message Service Handler Acknowledgment) is not received for a transaction, then:
3.
•
TSS
•
Relacom will resend the trans with increasing interval during 24h
•
Eltel
will resend the trans every 10 minutes during 24h (given http-return is received, see 1 above)
will resend the trans every 10 minutes during 24h (given http-return is received, see 1 above)
Heart-beat
TSS sends fictitious orders (also called Topaz-order) every 15 minutes to be able to supervise the functionality of the
flow also when normal traffic is low.
4.
Transaction alarm
•
TSS
•
Relacom will supervise TSS heart-beat
•
Eltel
If OA is not received by TSS within X minutes after OR is sent,
TSS supervision staff will be notified (historically called 15-minutes alarm).
The time is configurable per business agreement.
will supervise TSS heart-beat
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 4
Dialogue Overview
1.
NegotiateOrder
[nebi.biz:BC:NegotiateOrder_3.0]
2.
NegotiateOrder with order content negotiation
[nebi.biz:BC:NegotiateOrder_4.0]
3.
RenegotiateOrder initiated by TSS
[nebi.biz:BC:RenegotiateOrder_3.0]
4.
RenegotiateOrder intiated by Supplier alt A
[nebi.biz:BC:RenegotiateOrder_3.0]
5.
RenegotiateOrder initiated by Supplier alt B
[nebi.biz:BC:RenegotiateOrder_4.0]
6.
CancelOrder
[nebi.biz:BC:CancelOrder_3.0]
7.
ExecuteOrder
[nebi.biz:BC:ExecuteOrder_3.0]
8.
ExecuteOrder with transaction complaint
[nebi.biz:BC:ExecuteOrder_3.1]
9.
ExecuteOrder with delivery acceptance
[nebi.biz:BC:ExecuteOrder_4.0]
10.
ExecuteOrder w delivery acc + trans complaint
[nebi.biz:BC:ExecuteOrder_4.1]
11.
ExecuteOrder w partial execution + delivery acc
[nebi.biz:BC:ExecuteOrder_4.2]
12.
InvoiceDetail
[nebi.biz:BC:InvoiceDetail_4.0]
13.
RequestRequisite
[nebi.biz:BC:RequestRequisite_3.0]
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 5
NegotiateOrder [nebi.biz:BC:NegotiateOrder_3.0]
NeBI
TSS
Application
B2B
B2B
a) Send order
Supplier
Application
1. OrderRequest
ByBuyer
b) Is the order
acceptable?
2. OrderAcknowledgment
BySupplier
3. DialogueCancellation
BySupplier
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
c) Accept
order
d) Reject
order
sid 6
NegotiateOrder with order content negotiation [nebi.biz:BC:NegotiateOrder_4.0]
NeBI
TSS
Application
B2B
B2B
a) Send order
Supplier
Application
1. OrderRequest
ByBuyer
2. OrderAcknowledgment
BySupplier
c) Accept
order
3. DialogueCancellation
BySupplier
d) Reject
order
4. OrderRequest
BySupplier
e) Change
order
b) Is the
order
acceptable?
f) Is the
change
acceptable?
i) Change
Supplier
order
g) Accept
changed
order
h) Reject
order
5. OrderAcknowledgment
ByBuyer
6. DialogueCancellation
ByBuyer
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 7
RenegotiateOrder initiated by TSS [nebi.biz:BC:RenegotiateOrder_3.0]
NeBI
TSS
Application
B2B
B2B
a) Change
order
Supplier
Application
1. OrderUpdateRequest
ByInitiator
b) Is the change
acceptable?
2. OrderUpdateAcknowledgment
ByResponder
c) Accept
change
3. DialogueCancellation
ByResponder
d) Reject
change
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 8
RenegotiateOrder initiated by Supplier alt A [nebi.biz:BC:RenegotiateOrder_3.0]
NeBI
TSS
Application
Supplier
B2B
B2B
1. OrderUpdateProposalRequest
ByInitiator
Application
a) Request
Order change
b) Is the
change
acceptable?
c) Reject the
change
request
d) Change
the order
2. DialogueCancellation
ByResponder
3. OrderUpdateRequest
ByResponder
e) If the OUPR
concerns a
cancellation the
dialogue is
ended and TSS
initiates a new
CancelOrder
dialogue.
f) Is the
change
acceptable?
4. OrderUpdateAcknowledgment
ByInitiator
g) Accept the
change
5. DialogueCancellation
ByInitiator
h) Reject the
change
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 9
RenegotiateOrder initiated by Supplier alt B [nebi.biz:BC:RenegotiateOrder_4.0]
NeBI
TSS
Application
Supplier
B2B
B2B
1. OrderUpdateRequest
BySupplier
Application
a) Change
order
b) Is the
change
acceptable?
c) Accept
order
change
d) Reject
order
change
2. OrderUpdateAcknowledgment
ByBuyer
3. DialogueCancellation
ByBuyer
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 10
CancelOrder [nebi.biz:BC:CancelOrder_3.0]
NeBI
TSS
Application
B2B
B2B
a) Cancel
order
Supplier
Application
1. OrderCancellationRequest
b) Is the
cancellation
acceptable?
2. OrderCancellation
c) Accept
cancellation
3. DialogueCancellation
ByResponder
d) Reject
cancellation
Comments to c)
• If Supplier wants payment for the
cancelled order, Reason.Name is
set to 'faktureras’ in OC and
ESN2+OE are sent in an
ExecuteOrder dialogue.
• In rare occasions, Supplier will
not be able to send ”OC
faktureras”. This will not give
TSS problems.
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 11
ExecuteOrder [nebi.biz:BC:ExecuteOrder_3.0]
NeBI
TSS
Application
Supplier
B2B
B2B
1. ExecutionStatusNotification 1
b) Report event
2. ExecutionStatusNotification 2
f) Send
WorkReportReady
ÅtagandeDelvisKlart
ÅtagandeKlart
(OPER)
(OER)
a) For every
ESN1 event
i) Send
CommitmentReady
3. OrderExecuted
OE events
CommitmentPartlyReady
CommitmentReady
Application
ESN2 events
ProvisionalWorkReport PreliminärArbetsrapport
WorkReportReady
ArbetsrapportKlar
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
ESN1 events
Distributed
WorkBegun
SubReport
Message
Dormant
Resumed
ObjectReady
Utlämnad
ArbetePåbörjat
Delrapport
Meddelande
Vilande
Återupptaget
AnläggningKlar
sid 12
ExecuteOrder with transaction complaint [nebi.biz:BC:ExecuteOrder_3.1]
NeBI
TSS
Application
Supplier
B2B
B2B
1. ExecutionStatusNotification 1
c) Bad
ESN
Application
a) For every
ESN1 event
b) Report event
2. TransactionComplaint
d) Reject ESN
e) A TC with status ’reject’ means the
faulty trans has not updated the order,
while status ’complaint’ means the order
has been updated with the correct parts
of the defect trans.
3. ExecutionStatusNotification 2
g) Bad
ESN
h) Reject ESN
4. TransactionComplaint
i) Send
CommitmentReady
5. OrderExecuted
j) Bad
OE
f) Send
WorkReportReady
k) Reject OE
6. TransactionComplaint
OE events
CommitmentPartlyReady
CommitmentReady
ÅtagandeDelvisKlart
ÅtagandeKlart
(OPER)
(OER)
ESN2 events
ProvisionalWorkReport PreliminärArbetsrapport
WorkReportReady
ArbetsrapportKlar
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
ESN1 events
Distributed
WorkBegun
SubReport
Message
Dormant
Resumed
ObjectReady
Utlämnad
ArbetePåbörjat
Delrapport
Meddelande
Vilande
Återupptaget
AnläggningKlar
sid 13
ExecuteOrder with delivery acceptance [nebi.biz:BC:ExecuteOrder_4.0]
NeBI
TSS
Application
Supplier
B2B
B2B
Application
1. ExecutionStatusNotification 1
b) Report event
2. ExecutionStatusNotification 2
c) Send
WorkReportReady
3. OrderExecutedRequest
d) Send
CommitmentReady
a) For every
ESN1 event
e) Is
executedreport
acceptable?
f) Reject
4. OrderExecutedDenial
CommitmentReady
g) Accept
CommitmentReady
5. OrderExecutedAcknowledgment
OE events
CommitmentPartlyReady
CommitmentReady
ÅtagandeDelvisKlart
ÅtagandeKlart
(OPER)
(OER)
ESN2 events
ProvisionalWorkReport PreliminärArbetsrapport
WorkReportReady
ArbetsrapportKlar
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
ESN1 events
Distributed
WorkBegun
SubReport
Message
Dormant
Resumed
ObjectReady
Utlämnad
ArbetePåbörjat
Delrapport
Meddelande
Vilande
Återupptaget
AnläggningKlar
sid 14
ExecuteOrder w delivery acc + trans complaint [nebi.biz:BC:ExecuteOrder_4.1]
NeBI
TSS
Application
Supplier
B2B
B2B
1. ExecutionStatusNotification 1
c) Bad
ESN
g) Reject ESN
k) Is
executed
report
acceptable
?
a) For every
ESN1 event
e) Send
WorkReportReady
4. TransactionComplaint
h) Send
CommitmentReady
5. OrderExecutedRequest
i) Bad
OER
b) Report event
2. TransactionComplaint
d) Reject ESN
3. ExecutionStatusNotification 2
f) Bad
ESN
Application
j) Reject OER
6. TransactionComplaint
n) A TC with status ’reject’ means the
faulty trans has not updated the order,
while status ’complaint’ means the order
has been updated with the correct parts
of the defect trans.
l) Reject
7. OrderExecutedDenial
CommitmentReady
m) Accept
8. OrderExecutedAcknowledgment
CommitmentReady
OE events
CommitmentReady
ÅtagandeKlart
(OER)
ESN2 events
ProvisionalWorkReport PreliminärArbetsrapport
WorkReportReady
ArbetsrapportKlar
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
ESN1 events
Distributed
WorkBegun
SubReport
Message
Dormant
Resumed
ObjectReady
Utlämnad
ArbetePåbörjat
Delrapport
Meddelande
Vilande
Återupptaget
AnläggningKlar
sid 15
ExecuteOrder w partial execution + delivery acc [nebi.biz:BC:ExecuteOrder_4.2]
Business App
TSS
NeBI
B2B
B2B
1. OrderPartlyExecutedRequest
Supplier
Business App
a) Report CommitmentPartlyReady
e) Is
commitment
really partly
ready?
b) Reject
commitmentPartlyReady
2. OrderPartlyExecutedDenial
c) Accept
commitmentPartlyReady
3. OrderPartlyExecutedAcknowledgment
4. ExecutionStatusNotification 1
Distributed / WorkBegun
5. ExecutionStatusNotification 1
SubReport / Message /
Dormant / Resumed
6. ExecutionStatusNotification 1
ObjectReady
7. ExecutionStatusNotification 2
ProvisionalWorkReport
8. ExecutionStatusNotification 2
WorkReportReady
9. OrderExecutedRequest
j) Is
commitment
really ready?
k) Reject
commitmentReady
l) Accept
commitmentReady
The grey area is
optional and may be
repeated before
WorkReportReady
d) Report event
a) For each
event
e) Report event
a) For each event
(optional and
repeatable)
f) Report event
g) Send ProvisionalWorkReport
a) For every PWR
(optional and
repeatable)
h) Send
WorkReportReady
i) Send
CommitmentReady
10. OrderExecutedDenial
11. OrderExecutedAcknowledgment
OE events
CommitmentPartlyReady
CommitmentReady
ÅtagandeDelvisKlart
ÅtagandeKlart
(OPER)
(OER)
ESN2 events
ProvisionalWorkReport PreliminärArbetsrapport
WorkReportReady
ArbetsrapportKlar
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
ESN1 events
Distributed
WorkBegun
SubReport
Message
Dormant
Resumed
ObjectReady
Utlämnad
ArbetePåbörjat
Delrapport
Meddelande
Vilande
Återupptaget
AnläggningKlar
sid 16
InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0]
NeBI
TSS
Application
Supplier
B2B
B2B
1. InvoiceDetail
Application
a) Send
InvoiceDetailPart
a) ID is sent for
every
InvoiceDetailPart
b) Is the
InvoiceDetail
Correct?
c) Ok
d) Not Ok
2. InvoiceDetailAcknowledgment
3. InvoiceDetailComplaint
- All parts are sent
in the same
conversation
- IDA/IDC must
arrive before
sending next
part
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 17
RequestRequisite [nebi.biz:BC:RequestRequisite_3.0]
NeBI
TSS
Application
Supplier
B2B
B2B
Application
1. transaction
BTA:RequisiteRequest
a. BD:RequisiteRequest
a) Send
request
Find Requisite
b. BD:Requisite
Observe that BTA:RequisiteRequest,
unlike all other transactions in this
document, is a transaction that has a reply
that contains a business document.
The dialogue RequestRequisite consists of
only one transaction,
BTA:RequisiteRequest.
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 18
Dialogue Rules
1.
A dialogue defines a transaction pattern between two parties
2.
A conversation is an instance of a dialogue. It is identified by its conversationId which must be unique.
3.
Every transaction contains a conversationId so that the receiving party can associate the transaction
with a conversation
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 19
Inter-dialogue Rules 1
Within each dialogue the process rules are illustrated by the sequence diagrams in the previous slides. The following slides
describe inter-dialogue rules that are rules that apply to concurrent dialogues that concern the same order.
Principal rules
1.
The first dialogue for every order is NegotiateOrder
2.
Concurrent dialogues concerning the same order are permitted
3.
Transactions are not permitted towards an order with a completed ExecuteOrder dialogue
4.
An order is identified by its OrderId which must be unique
The rule means that every NegotiateOrder dialogue concerns a new order with a unique orderid (see below for order resend though).
When a new unique order is rejected in the NegotiateOrder dialogue using DialogueCancellation, then the order, including its orderid, is
regarded as non-existant. The orderid of the rejected order may be reused in a new NegotiateOrder dialogue.
In a conversation of dialogue type ”NegotiateOrder with order content negotiation” all transactions, possibly including multiple OrderRequest
transactions operate on the same order, thus using the same orderId. This does not violate the rule since the the same conversation is used.
5.
Resending an order is allowed if the “resend flag” is set
When resending, the order content is identical, apart from the resend flag. Resending is done when an order needs to be sent through the
regular channel at a time when it has already reached the Supplier through an alternative channel.
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 20
Inter-dialogue Rules 2
Exceptions, additions and explanations
1.
The dialogue NegotiateOrder must be finished before starting ExecuteOrder
[OA before ESN/OE]
Info: Some violations of the rule occurs for technical reasons, since the IT components between the business application endpoints not always
manage to maintain the original business application transaction sequence. The reason is that the IT components have parallel execution
threads. This problem is most common during recovery after a stop.
2.
ESN2/OE is not allowed to be sent during an ongoing RenegotiateOrder initiated by supplier
TSS will reply with TransactionComplaint.
Info: If TSS does not respond to OrderUpdate(Proposal)Request in a timely manner, the Supplier should contact TSS through other channels.
3.
WorkReportReady (ESN2) confirms cancellation request (OCR)
[ESN2 = OC + ESN2]
Explanation: Supplier does not need to confirm OCR with OC if Supplier sends ESN2 in the dialogue ExecuteOrder, see slide CancelOrder.
4.
In the dialogue RenegotiateOrder initiated by supplier, an ”impossible” orderchange (OUR) as an answer
to OUPR may be rejected by the Supplier
Info: Subsequent status reporting (ESN/OE) is allowed, but cannot be handled by TSS. Manual routines must be used.
5.
Supplier may initiate multiple simultanous RenegotiateOrder dialogues
Info: TSS will however reject new instances of RenegotiateOrder initiated by supplier. Supplier must wait for the ongoing dialogue to complete or
contact TSS through other channels in order to solve the problem.
dokID: Telia AB CIO Office nr 2002/007/1, rev J2, 2008-10-01 [Approved: J Alatalo, SIG]
sid 21