1 / 21

Process Flow for TSS - Supplier

This document outlines the process and interdialogue rules for the NeBI interface between TSS and subcontractors.

irad
Download Presentation

Process Flow for TSS - Supplier

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Process Flow for TSS - Supplier This document describes the process and interdialogue rules in the NeBI interface between TSS and subcontractors.Security: Public

  2. 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 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, 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 accImproved slides: slides 12-15, EO variants: statuses; slide 21: Inter-dialogue Rules 2 2010-08-24 Per Rudal J3 Slide 17, InvoiceDetail_4.0 clarified wrt resend of corrected InvoiceDetail msgs

  3. Transaction Pattern NeBI Responder Initiator 1. B2B Application 2. Request (dialog + trans) B2B 3. ebMS service + action (=dialog + trans) 4. ebMS header validation Trans A 6. Ack / Error 5. MSHack / Error 7. Application 8. Request (dialog + trans) 9. Dialog X 10. 11. Request (dialog + trans) 12. ebMS service + action (=dialog + trans) 13. ebMS header validation Trans B 15. Ack / Error 14. MSHack / Error 16. Request (dialog + trans) 17. • 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 transaction request, which is an http-request holding one ebMS-message including a business document, e g an Order • A transaction reply, which is a new separate http-request holding one ebMS-message containing an MSH-ack or Error

  4. Resending, Heart-beat and Alarms This slide describes the resending pattern, heart-beats and alarms for (missing) events in the NeBI interface.All values are configurable. Representative but not necessarily actual values are shown.Values for some contractors are shown as examples. • Resending on http-levelIf http-returnis not received for an http-request, then: • TSS will resendthe http-request every4min7times • Eltel will resend the http-request every 120s during 24h • Resending on transaction levelIf MSH-ack (Message Service Handler Acknowledgment) is not received for a transaction, then: • TSS will resendthe trans every 10 minutesduring 24h (given http-return is received, see 1 above) • Relacom will resendthe transwith increasing intervalduring 24h • Eltel will resendthe trans every10 minutesduring 24h (given http-return is received, see 1 above) • Heart-beatTSS sends fictitious orders (also called Topaz-order) every 15 minutes (configurable per contractor) to be able to supervise the functionality of the flow also when normal traffic is low. • Transaction alarm • TSS If OA is not received by TSS withinX minutesafter 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

  5. Dialogue Overview • NegotiateOrder [nebi.biz:BC:NegotiateOrder_3.0] • NegotiateOrder with order content negotiation [nebi.biz:BC:NegotiateOrder_4.0] • RenegotiateOrderinitiated by TSS [nebi.biz:BC:RenegotiateOrder_3.0] • RenegotiateOrderintiated by Supplier alt A [nebi.biz:BC:RenegotiateOrder_3.0] • RenegotiateOrderinitiated by Supplier alt B [nebi.biz:BC:RenegotiateOrder_4.0] • CancelOrder [nebi.biz:BC:CancelOrder_3.0] • ExecuteOrder [nebi.biz:BC:ExecuteOrder_3.0] • ExecuteOrder with transaction complaint [nebi.biz:BC:ExecuteOrder_3.1] • ExecuteOrder with delivery acceptance [nebi.biz:BC:ExecuteOrder_4.0] • ExecuteOrder w delivery acc + trans complaint [nebi.biz:BC:ExecuteOrder_4.1] • ExecuteOrder w partial execution + delivery acc [nebi.biz:BC:ExecuteOrder_4.2] • InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0] • RequestRequisite [nebi.biz:BC:RequestRequisite_3.0]

  6. NegotiateOrder[nebi.biz:BC:NegotiateOrder_3.0] Supplier TSS Application B2B B2B Application NeBI 1. OrderRequestByBuyer a) Send order b) Is the order acceptable? 2. OrderAcknowledgment BySupplier c) Accept order d) Reject order 3. DialogueCancellationBySupplier

  7. NegotiateOrderwith order content negotiation [nebi.biz:BC:NegotiateOrder_4.0] Supplier TSS Application B2B B2B Application NeBI 1. OrderRequestByBuyer a) Send order b) Is the order acceptable? 2. OrderAcknowledgment BySupplier c) Accept order d) Reject order 3. DialogueCancellationBySupplier e) Change order 4. OrderRequestBySupplier f) Is the change acceptable? g) Accept changed order 5. OrderAcknowledgmentByBuyer i) Change Supplier order 6. DialogueCancellationByBuyer h) Reject order

  8. RenegotiateOrder initiated by TSS[nebi.biz:BC:RenegotiateOrder_3.0] Supplier TSS Application B2B B2B Application NeBI 1. OrderUpdateRequestByInitiator a) Change order b) Is the change acceptable? c) Accept change 2. OrderUpdateAcknowledgment ByResponder d) Reject change 3. DialogueCancellationByResponder

  9. RenegotiateOrder initiated by Supplier alt A[nebi.biz:BC:RenegotiateOrder_3.0] Supplier TSS Application B2B B2B Application NeBI a) Request Order change 1. OrderUpdateProposalRequestByInitiator b) Is the change acceptable? c) Reject the change request 2. DialogueCancellationByResponder 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. f) Is the change acceptable? g) Accept the change 4. OrderUpdateAcknowledgment ByInitiator h) Reject the change 5. DialogueCancellation ByInitiator

  10. RenegotiateOrder initiated by Supplier alt B[nebi.biz:BC:RenegotiateOrder_4.0] Supplier TSS Application B2B B2B Application NeBI a) Change order 1. OrderUpdateRequestBySupplier b) Is the change acceptable? c) Accept order change 2. OrderUpdateAcknowledgmentByBuyer d) Reject order change 3. DialogueCancellationByBuyer

  11. CancelOrder[nebi.biz:BC:CancelOrder_3.0] Supplier TSS Application B2B B2B Application NeBI a) Cancel order 1. OrderCancellationRequest b) Is the cancellation acceptable? c) Accept cancellation 2. OrderCancellation d) Reject cancellation 3. DialogueCancellationByResponder • Comments to c) • If Supplier wants paymentfor 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.

  12. ExecuteOrder[nebi.biz:BC:ExecuteOrder_3.0] TSS Application B2B Supplier B2B Application NeBI b) Report event a) For every ESN1 event 1. ExecutionStatusNotification 1 f) Send WorkReportReady 2. ExecutionStatusNotification 2 i) Send CommitmentReady 3. OrderExecuted ESN1 eventsDistributed UtlämnadWorkBegun ArbetePåbörjatSubReport DelrapportMessage MeddelandeDormant VilandeResumed ÅterupptagetObjectReady AnläggningKlar OE eventsCommitmentPartlyReady ÅtagandeDelvisKlart (OPER)CommitmentReady ÅtagandeKlart (OE) ESN2 eventsProvisionalWorkReport PreliminärArbetsrapportWorkReportReady ArbetsrapportKlar

  13. ExecuteOrderwith transaction complaint[nebi.biz:BC:ExecuteOrder_3.1] TSS Application B2B Supplier B2B Application NeBI a) For every ESN1 event b) Report event 1. ExecutionStatusNotification 1 c) BadESN 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. f) Send WorkReportReady 3. ExecutionStatusNotification 2 g) BadESN h) Reject ESN 4. TransactionComplaint i) Send CommitmentReady 5. OrderExecuted j) BadOE k) Reject OE 6. TransactionComplaint ESN1 eventsDistributed UtlämnadWorkBegun ArbetePåbörjatSubReport DelrapportMessage MeddelandeDormant VilandeResumed ÅterupptagetObjectReady AnläggningKlar OE eventsCommitmentPartlyReady ÅtagandeDelvisKlart (OPER)CommitmentReady ÅtagandeKlart (OE) ESN2 eventsProvisionalWorkReport PreliminärArbetsrapportWorkReportReady ArbetsrapportKlar

  14. ExecuteOrderwith delivery acceptance[nebi.biz:BC:ExecuteOrder_4.0] Supplier TSS Application B2B B2B Application NeBI a) For every ESN1 event b) Report event 1. ExecutionStatusNotification 1 c) Send WorkReportReady 2. ExecutionStatusNotification 2 d) SendCommitmentReady 3. OrderExecutedRequest e) Is executedreport acceptable? f) Reject CommitmentReady 4. OrderExecutedDenial g) AcceptCommitmentReady 5. OrderExecutedAcknowledgment ESN1 eventsDistributed UtlämnadWorkBegun ArbetePåbörjatSubReport DelrapportMessage MeddelandeDormant VilandeResumed ÅterupptagetObjectReady AnläggningKlar OE eventsCommitmentPartlyReady ÅtagandeDelvisKlart (OPER)CommitmentReady ÅtagandeKlart (OER) ESN2 eventsProvisionalWorkReport PreliminärArbetsrapportWorkReportReady ArbetsrapportKlar

  15. ExecuteOrderw delivery acc + trans complaint[nebi.biz:BC:ExecuteOrder_4.1] Supplier TSS Application B2B B2B Application NeBI a) For every ESN1 event b) Report event 1. ExecutionStatusNotification 1 c) BadESN 2. TransactionComplaint d) Reject ESN e) Send WorkReportReady 3. ExecutionStatusNotification 2 f) BadESN g) Reject ESN 4. TransactionComplaint h) SendCommitmentReady 5. OrderExecutedRequest i) BadOER 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 CommitmentReady k) Isexecutedreport acceptable? 7. OrderExecutedDenial m) AcceptCommitmentReady 8. OrderExecutedAcknowledgment ESN1 eventsDistributed UtlämnadWorkBegun ArbetePåbörjatSubReport DelrapportMessage MeddelandeDormant VilandeResumed ÅterupptagetObjectReady AnläggningKlar ESN2 eventsProvisionalWorkReport PreliminärArbetsrapportWorkReportReady ArbetsrapportKlar OE eventsCommitmentReady ÅtagandeKlart (OER)

  16. ExecuteOrderw partial execution + delivery acc[nebi.biz:BC:ExecuteOrder_4.2] TSS Supplier Business App B2B B2B Business App 4. ExecutionStatusNotification 1Distributed / WorkBegun d) Report event a) For each event 8. ExecutionStatusNotification 2WorkReportReady h) Send WorkReportReady i) Send CommitmentReady 9. OrderExecutedRequest NeBI a) Report Commitment-PartlyReady 1. OrderPartlyExecutedRequest b) Reject commitmentPartlyReady e) Iscommitment really partly ready? 2. OrderPartlyExecutedDenial The grey area is optional and may be repeated before WorkReportReady c) Accept commitmentPartlyReady 3. OrderPartlyExecutedAcknowledgment 5. ExecutionStatusNotification 1SubReport / Message / Dormant / Resumed a) For each event(optional and repeatable) e) Report event 6. ExecutionStatusNotification 1ObjectReady f) Report event 7. ExecutionStatusNotification 2ProvisionalWorkReport a) For every PWR(optional and repeatable) g) Send Provisional- WorkReport k) Reject commitmentReady 10. OrderExecutedDenial j) Iscommitment really ready? ESN1 eventsDistributed UtlämnadWorkBegun ArbetePåbörjatSubReport DelrapportMessage MeddelandeDormant VilandeResumed ÅterupptagetObjectReady AnläggningKlar l) Accept commitmentReady 11. OrderExecutedAcknowledgment OE eventsCommitmentPartlyReady ÅtagandeDelvisKlart (OPER)CommitmentReady ÅtagandeKlart (OER) ESN2 eventsProvisionalWorkReport PreliminärArbetsrapportWorkReportReady ArbetsrapportKlar

  17. InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0] Supplier TSS Application B2B B2B Application NeBI a) SendInvoiceDetailPart 1. InvoiceDetail a) ID is sent for every InvoiceDetailPart b) Is the InvoiceDetail Correct? b) Rejected ID’s are corrected and resent c) Ok 2. InvoiceDetailAcknowledgment 3. InvoiceDetailComplaint d) Not Ok • a) A large ID must be split in several InvoiceDetailParts due to technical limitations • All parts of an ID are sent in the same conversation • IDA/IDC for a part must arrive before sending next part b) A corrected ID is sent in the same conv as the faulty ID w new IssuedDateTime

  18. RequestRequisite[nebi.biz:BC:RequestRequisite_3.0] Supplier TSS Application B2B B2B Application NeBI 1. transactionBTA:RequisiteRequest a) Send request a. BD:RequisiteRequest 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.

  19. Dialogue Rules • A dialogue defines a transaction pattern between two parties • A conversation is an instance of a dialogue. It is identified by its conversationId which must be unique. • Every transaction contains a conversationId so that the receiving party can associate the transaction with a conversation

  20. 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 • The first dialogue for every order is NegotiateOrder • Concurrent dialogues concerning the same order are permitted • Transactions are not permitted towards an order with a completed ExecuteOrder dialogue • 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 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. • 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 the Supplier through an alternative channel.

  21. Inter-dialogue Rules 2 • Exceptions, additions and explanations • 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. • ESN2/OE is not allowed to be sent during an ongoing RenegotiateOrder initiated by supplierTSS 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. • 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. • In the dialogue RenegotiateOrder initiated by supplier, 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. • Supplier may initiate multiple simultanous RenegotiateOrder dialoguesInfo: TSS will however reject newinstances of RenegotiateOrder initiated by supplier. Supplier must wait for the ongoing dialogue to complete or contact TSS through other channelsin order to solve the problem.

More Related