Process Flow for TSS - Supplier

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 1

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 PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 2

Document History2003-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 OEAjusterade 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*4minslide 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 MNy layout. Ny slide 6, NegotiateOrder med förhandling + slide 4, Dialogöversikt uppdaterad

2007-01-19 Hans Guste, Per Rudal 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-05-30 Per Rudal PK1 New slide 4 Transaction Validation and Feedback. Slide 3 Transaction Pattern: Improved text

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 3

Transaction Pattern

Responder

2. Request (dialog + trans)

4. ebMS header validation

13. ebMS header validation

NeBI

App

licat

ion

App

licat

ion

Tra

ns

B

Tra

ns

AInitiator

8. Request (dialog + trans)

11. Request (dialog + trans)

16. Request (dialog + trans)

6. Ack / Error

15. Ack / Error

1.

7.

9.

10.

17.

Dia

log

X

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

3. ebMS service + action (=dialog + trans)

5. MSHack / Error

14. MSHack / Error

12. ebMS service + action (=dialog + trans)

B2B

B2B

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 4

Transaction Validation and FeedbackPart X

B2BBusiness App

Part Y

B2B Business App

Trans C

Trans B

j) Send msgtype C

f) Send msgtype B

NeBI

3. Trans B

5. Trans C

e) Business logic

Trans A1. Trans Aa) Send msgtype A

b) Is Trans A valid?

2a. Transaction Reject

c) Is Trans A valid?

1b. MSH ack

1a. Error

2b. Transaction Complaint

4a. Transaction Reject

3b. MSH ack

3a. Error

4b. Transaction Complaint

g) Is Trans B valid?

h) Is Trans B valid?

d) Correct msg

i) Correct msg

k) Is Trans C valid?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 5

Resending, Heart-beat and Alarms

1. Resending on http-levelIf http-return is not received for an http-request, then:

• TSS will resend the http-request every 4min 7times

• Eltel will resend the http-request every 120s during 24h

2. Resending on transaction levelIf MSH-ack (Message Service Handler Acknowledgment) is not received for a transaction, then:

• TSS will resend the trans every 10 minutes during 24h (given http-return is received, see 1 above)

• 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)

3. Heart-beatTSS 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 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.

• Relacom will supervise TSS heart-beat

• Eltel will supervise TSS heart-beat

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. 

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 6

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. InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0]

12. RequestRequisite [nebi.biz:BC:RequestRequisite_3.0]

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 7

NegotiateOrder [nebi.biz:BC:NegotiateOrder_3.0]

TSS

B2BApplication

Supplier

B2B Application1. OrderRequest

ByBuyer

d) Rejectorder

c) Acceptorder

a) Send order

NeBI

2. OrderAcknowledgmentBySupplier

3. DialogueCancellationBySupplier

b) Is the order acceptable?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 8

NegotiateOrder with order content negotiation [nebi.biz:BC:NegotiateOrder_4.0]

TSS

B2BApplication

Supplier

B2B Application1. OrderRequest

ByBuyer

d) Reject order

c) Acceptorder

a) Send order

NeBI

2. OrderAcknowledgmentBySupplier

3. DialogueCancellationBySupplier

b) Is the order

acceptable?

e) Change order

4. OrderRequestBySupplier

5. OrderAcknowledgmentByBuyer

g) Accept changed

order

6. DialogueCancellationByBuyer

h) Reject order

f) Is the change

acceptable?

i) Change Supplier

order

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 9

RenegotiateOrder initiated by TSS [nebi.biz:BC:RenegotiateOrder_3.0]

TSS

B2BApplication

Supplier

B2B Application1. OrderUpdateRequest

ByInitiator

d) Reject change

c) Accept change

a) Change order

NeBI

2. OrderUpdateAcknowledgmentByResponder

3. DialogueCancellationByResponder

b) Is the change acceptable?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 10

RenegotiateOrder initiated by Supplier alt A [nebi.biz:BC:RenegotiateOrder_3.0]

TSS

B2BApplication

Supplier

B2B Application

NeBI

a) RequestOrder change

1. OrderUpdateProposalRequestByInitiator

2. DialogueCancellationByResponder

c) Reject the change request

3. OrderUpdateRequest ByResponder

d) Change the order

e) If the OUPR concerns a

cancellation the dialogue is

ended and TSS initiates a new CancelOrder

dialogue.

b) Is the change

acceptable?

h) Reject the change

g) Accept the change

4. OrderUpdateAcknowledgmentByInitiator

5. DialogueCancellation ByInitiator

f) Is the change

acceptable?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 11

RenegotiateOrder initiated by Supplier alt B [nebi.biz:BC:RenegotiateOrder_4.0]

TSS

B2BApplication

Supplier

B2B Application

NeBI

a) Changeorder

1. OrderUpdateRequestBySupplier

2. OrderUpdateAcknowledgmentByBuyer

c) Accept order

change

3. DialogueCancellationByBuyer

d) Reject order

change

b) Is the change

acceptable?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 12

CancelOrder [nebi.biz:BC:CancelOrder_3.0]

TSS

B2BApplication

Supplier

B2B Application

1. OrderCancellationRequest

d) Reject cancellation

c) Acceptcancellation

a) Cancelorder

NeBI

2. OrderCancellation

3. DialogueCancellationByResponder

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 able to send ”OC faktureras”. This will not give TSS problems.

b) Is the cancellation acceptable?

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 13

ExecuteOrder [nebi.biz:BC:ExecuteOrder_3.0]

TSS

B2BApplication

Supplier

B2B Application

NeBI

b) Sendstatus1. ExecutionStatusNotification 1

c) Sendworkreport2. ExecutionStatusNotification 2

d) Sendexecutedreport3. OrderExecuted

a) ESN1 is sent for every status change before workReport

workReport = ’Arbetsrapport’executedReport = ’Åtagande klart’

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 14

ExecuteOrder with transaction complaint [nebi.biz:BC:ExecuteOrder_3.1]

TSS

B2BApplication

Supplier

B2B Application

NeBI

b) Sendstatus1. ExecutionStatusNotification 1

a) ESN1 is sent for every status change before workReport

workReport = ’Arbetsrapport’executedReport = ’Åtagande klart’

f) SendworkReport3. ExecutionStatusNotification 2

i) SendexecutedReport 5. OrderExecuted

2. TransactionComplaintd) Reject ESNc) BadESN

4. TransactionComplaintg) BadESN

h) Reject ESN

6. TransactionComplaintj) Bad

OEk) Reject OE

e) A TC with status ’reject’ means the faulty trans has not updated the order state, while status ’complaint’ means the order state has been updated with the correct parts of the faulty trans.

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 15

ExecuteOrder with delivery acceptance [nebi.biz:BC:ExecuteOrder_4.0]

TSS

B2BApplication

Supplier

B2B Application

NeBI

c) Send workreport

2. ExecutionStatusNotification 2

d) Sendexecutedreport3. OrderExecutedRequest

5. OrderExecutedAcknowledgmentg) Accept

executedreport

4. OrderExecutedDenialf) Rejectexecutedreport

e) Is executedreport

acceptable?

b) Sendstatus1. ExecutionStatusNotification 1

a) ESN1 is sent for every status change before workReport

workReport = ’Arbetsrapport’executedReport = ’Åtagande klart’

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 16

ExecuteOrder w delivery acc + trans complaint [nebi.biz:BC:ExecuteOrder_4.1]

TSS

B2BApplication

Supplier

B2B Application

NeBI

8. OrderExecutedAcknowledgmentm) Accept

executedreport

7. OrderExecutedDeniall) Reject

executedreportk) Is

executedreport

acceptable?

b) Sendstatus1. ExecutionStatusNotification 1

a) ESN1 is sent for every status change before workReport

workReport = ’Arbetsrapport’executedReport = ’Åtagande klart’

e) SendworkReport3. ExecutionStatusNotification 2

2. TransactionComplaintd) Reject ESNc) BadESN

4. TransactionComplaintf) BadESN

g) Reject ESN

h) SendexecutedReport 5. OrderExecutedRequest

6. TransactionComplainti) BadOER

j) Reject OER

n) A TC with status ’reject’ means the faulty trans has not updated the order state, while status ’complaint’ means the order state has been updated with the correct parts of the faulty trans.

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 17

InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0]

TSS

B2BApplication

Supplier

B2B Application

NeBI

a) SendInvoiceDetailPart1. InvoiceDetail

2. InvoiceDetailAcknowledgmentc) Ok

3. InvoiceDetailComplaintd) Not Ok

b) Is the InvoiceDetail

Correct?

- All parts are sent in the same conversation

- IDA/IDC must arrive before sending next part

a) ID is sent for every

InvoiceDetailPart

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 18

1. transactionBTA:RequisiteRequest

RequestRequisite [nebi.biz:BC:RequestRequisite_3.0]

TSS

B2BApplication

Supplier

B2B Application

a. BD:RequisiteRequest a) Send request

NeBI

b. BD:Requisite

Find 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 PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 19

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 part can associate the transaction with a conversation

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 20

Inter-dialogue Rules 1Within 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 uniqueThe 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 dialogue of type ”NegotiateOrder with order content negotiation” all transactions, possibly including multiple OrderRequest transactions operate on the same order, thus using the same orderId.

5. Resending an order is allowed if the “resend flag” is setWhen 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 Supplier through a reserve channel.

dokID: Telia AB CIO Office nr 2002/007/1, rev PK1, 2008-05-30 [Approved: J Alatalo, SIG] sid 21

Inter-dialogue Rules 2

Exceptions, additions and explanations

1. The dialogue NegotiateOrder must be finished before starting ExecuteOrder [OA before ESN/OE]Info: Some violation 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 RenegOrderBySupTSS will reply with TC.Info: If RenegOrderBySup is not responded in a timely manner, the Supplier should contact TSS through other channels.

3. Workreport (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 RenegOrderBySup, an ”impossible” orderchange (OUR) as an answer to OUPR may be rejected by the SupplierInfo: Subsequent status reporting (ESN/OE) is allowed, but cannot be handled by TSS. Manual routines must be used.

5. A new dialogue RenegOrderBySup may be initiated while a RenegOrderBySup is ongoingInfo: TSS will however reject the new RenegOrderBySup. Supplier must wait for the ongoing dialogue to complete or contact TSS through other channels in order to solve the problem.