Zum Ende des Banners springen
Zum Anfang des Banners springen

3) Fehlschlag am Schalttag

Zum Ende der Metadaten springen
  • Erstellt von Former user , zuletzt geändert von Former user am Juni 01, 2023
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 24 Nächste Version anzeigen »

Beschreibung

TitelAuftrag (Providerwechsel / Verbundleistung) anlegen
Kurzbeschreibung

Folgender Ablauf beschreibt die typischen API Interaktionen zwischen dem aufnehmenden Auftrageber (EKPauf und TNBauf, aka AGauf), dem Leistungserbringer (LE, aka ANE) und dem abgebenden Auftraggeber (EKPab und TNBab, aka ABab) für die Anwendungsfälle "Auftrag (Providerwechsel / Verbundleistung) anlegen - Schlechtfall Negative RespondProviderChange (RUEM-PV)".

Zu diesen Anwendungsfall sind zwei Sequenzen relevant:

  • Die Vorabstimmung
  • Die Durchführung
Vorbedingung
  • Rahmenverträge und Dienstverträge sind vorhanden
  • Der Auftraggeber hat die Verfügbarkeit des Produktes geprüft
  • der AGab hat sich beim LE für Kündigungen durch den Leistungserbringer registriert (siehe Auftrag (Kündigung durch LE) anlegen)
Auslöser

Der aufnehmende Auftraggeber legt einen Auftrag für den Providerwechsel bzw. die Verbundleistung beim Leistungserbringer (ANE) an.

Schlechtfall: Am Schalttag kann die Bereitstellung nicht erfolgen. 

Ergebnis

Der Leistungserbringer fordert beim aufnehmenden Provider einen neuen Termin an (Status "Pending" - Information Required (TAM))

Der Leistungserbringer sendet an den abgebenden Provider eine Verzögerungsmeldung (ProcessingMessage "OrderDelay", (VZM-PV))

Nach erfolgter Terminverschiebung durch den aufnehmenden Provider sendet der Leistungserbringer an den abgebenden Provider eine Information über den neuen Bereitstellungstermin: ProcessingMessage "orderConfirmationUpdate", (erneute ABM-PV)

Der weitere Verlauf wird hier nicht mehr betrachtet.

Ablauf

Variante erfolgreiche Schaltung nach Terminanforderung

@startuml
autonumber
     
box Product Order vom Typ PV (PO)
participant eauf as "EKP auf + TNB auf (AG auf)"
participant tauf as "ANE (LEauf)"
     
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "ANE (LEab)"
participant tab as "TNB ab + EKPab (AG ab)"
     
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
note right: PV
  
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Acknowleged)
tauf -> leab: notifyKUE
note over leab, tab: Die Sequenz  [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=547957140#Auftrag(K%C3%BCndigungdurchLE,GFPV/VBL)anlegen-HappyPath Auftrag (Kündigung durch LE, GF PV/VBL, Happy path) anlegen]] wird hier includiert
leab ->tauf:notifyRUEM-PV(approval, reason)
 
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,pending)
tauf -> leab:notifyDelayed
leab -> tab: ProductOrderProcessingMessageEvent(PO2, delayMessage)
note right: VZM-PV
eauf <- tauf: ProductOrderInformationRequiredEvent(PO,requestedCompletionDate)
eauf -> tauf: POST RescheduleProductOrder
eauf <- tauf: POST RescheduleProductOrderStateChangeEvent(acknowledged, inProgress)
eauf <- tauf: POST ProductOrderAttributeValueChangeEvent(PO, requestedCompletionDate)
eauf <- tauf: POST RescheduleProductOrderStateChangeEvent(done)
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,Completed)
tauf -> leab:notifyInCompleted
leab -> tab: ProductOrderStatusChangeEvent(PO2, Completed)
note right: ERLM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,Closed)
tauf -> leab:notifyInClosed
leab -> tab: ProductOrderStatusChangeEvent(PO2, Closed)
note right: ENTM-PV
@enduml

Analog zu Erneute Auftragsbestätigung versenden müssen vor der zweiten ABM an AG auf und AGab noch AttributeValueChange auf das RequestedExecutionDate und ProcessingMessage vom Type "orderConfirmationUpdate" versendet werden.

Beispieldaten (linker Block, TNBauf ↔ ANE)

 Post ProductOrder (providerChange) - identisch zum Gutfall

 ProductOrderStateChangeEvent: Acknowledged - identisch zum Gutfall

 ProductOrderAttributeValueChange - identisch zum Gutfall

 ProductOrderStateChangeEvent: inProgress - identisch zu Gutfall und Geschäftsfall Neu


ProductOrderStateChangeEvent: pending

ProductOrderStateChangeEvent: pending
fachliche FelderDaten API Felder
Orderstatus pendingstate 
fachliches Änderungsdatum 2022-12-16T11:30:00+01:00stateChangeDate 
technisches EventDatum2022-12-16T11:30:00+01:00eventTime
Grund der Änderung

6001

"Endkunde nicht angetroffen"

stateChangeReason.code

stateChangeReason.description

ProductOrderInformationRequiredEvent

fachliche FelderDatenAPI Felder
fieldPath

/requestedCompletionDate

tbd

fieldPath.path

fieldPath.typeOfChange

POST RescheduleProductOrder

fachliche FelderDatenAPI Felder
Verschobener Kundenwunschtermin mit Zeitfenster

2022-12-19T08:00:00+01:00

2022-12-19T12:00:00+01:00

rescheduledRequestedCompletionTimePeriod.startDateTime

rescheduledRequestedCompletionTimePeriod.endDateTime

Verschiebungsgrund

003

Terminverschiebung nach TAM

rescheduleReason.code

rescheduleReason.description

POST RescheduleProductOrderStateChangeEvent: acknowledged

POST RescheduleProductOrderStateChangeEvent: inProgress

POST ProductOrderAttributeValueChangeEvent

POST RescheduleProductOrderStateChangeEvent: done

ProductOrderStateChangeEvent: completed

ProductOrderStateChangeEvent: closed

Variante LineInUse

@startuml
autonumber
     
box Product Order vom Typ PV (PO)
participant eauf as "EKP auf + TNB auf (AG auf)"
participant tauf as "ANE (LEauf)"
     
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "ANE (LEab)"
participant tab as "TNB ab + EKPab (AG ab)"
     
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
note right: PV
  
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Acknowleged)
tauf -> leab: notifyKUE
note over leab, tab: Die Sequenz  [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=547957140#Auftrag(K%C3%BCndigungdurchLE,GFPV/VBL)anlegen-HappyPath Auftrag (Kündigung durch LE, GF PV/VBL, Happy path) anlegen]] wird hier includiert
leab ->tauf:notifyRUEM-PV(approval, reason)
 
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,pending)
tauf -> leab:notifyInPending
leab -> tab: ProductOrderStatusChangeEvent(PO2, pending)
eauf <- tauf: ProductOrderInformationRequiredEvent(PO,requestedCompletionDate)
eauf -> tauf: POST CloseProductOrder
eauf <- tauf: POST CloseProductOrderStateChangeEvent(acknowledged, inProgress, done)
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,Completed)
tauf -> leab:notifyInCompleted
leab -> tab: ProductOrderStatusChangeEvent(PO2, Completed)
note right: ERLM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,Closed)
tauf -> leab:notifyInClosed
leab -> tab: ProductOrderStatusChangeEvent(PO2, Closed)
note right: ENTM-PV
@enduml

Analog zu Erneute Auftragsbestätigung versenden müssen vor der zweiten ABM an AG auf und AGab noch AttributeValueChange auf das RequestedExecutionDate und ProcessingMessage vom Type "orderConfirmationUpdate" versendet werden.

Variante Cancel

@startuml
autonumber
     
box Product Order vom Typ PV (PO)
participant eauf as "EKP auf + TNB auf (AG auf)"
participant tauf as "ANE (LEauf)"
     
box  (Sub)Product Order vom Typ KUE-LE (PO2)
participant leab as "ANE (LEab)"
participant tab as "TNB ab + EKPab (AG ab)"
     
eauf -> tauf: POST ProductOrder(productOrderItemCreate, VAId)
note right: PV
  
eauf <- tauf: ProductOrderStatusChangeEvent(PO, Acknowleged)
tauf -> leab: notifyKUE
note over leab, tab: Die Sequenz  [[https://confluence.t-systems-mms.eu/pages/viewpage.action?pageId=547957140#Auftrag(K%C3%BCndigungdurchLE,GFPV/VBL)anlegen-HappyPath Auftrag (Kündigung durch LE, GF PV/VBL, Happy path) anlegen]] wird hier includiert
leab ->tauf:notifyRUEM-PV(approval, reason)
 
eauf <- tauf: ProductOrderStateChangeEvent(PO,InProgress)
tauf -> leab:notifyInProgress
leab -> tab: ProductOrderStatusChangeEvent(PO2, InProgress)
note right: ABM-PV
eauf <- tauf: ProductOrderStateChangeEvent(PO,pending)
tauf -> leab:notifyInPending
leab -> tab: ProductOrderStatusChangeEvent(PO2, pending)
eauf <- tauf: ProductOrderInformationRequiredEvent(PO,requestedCompletionDate)
eauf -> tauf: POST CancelProductOrder
eauf <- tauf: POST CancelProductOrderStateChangeEvent(acknowledged, inProgress)
eauf <- tauf: ProductOrderStateChangeEvent(PO,assessingCancellation)
eauf <- tauf: ProductOrderStateChangeEvent(PO,Cancelled)
eauf <- tauf: POST CancelProductOrderStateChangeEvent(done)
tauf -> leab:notifyFailed
leab -> tab: ProductOrderStatusChangeEvent(PO2, failed)
note right: ABBM-PV

@enduml


Beispieldaten


  • Keine Stichwörter

Datenschutz
Impressum
Feedback