Orchestrator: Manage Cleaning Request State and Data

[nicoprow]

The BPDM Orchestrator should manage the life cycle of a cleaning request. By this it needs to implement a state machine, describing logic when the cleaning request moves from one state to another.

---
title: Cleaning Task Transition Logic
---
stateDiagram-v2
    
    state "Queued" as GenericCleaningQueued
    state "Reserved" as GenericCleaningReserved

    state "Queued" as BpnProcessingQueued
    state "Reserved" as BpnProcessingReserved

    state "Queued" as GoldenRecordUpdateQueued
    state "Reserved" as GoldenRecordUpdateReserved

    [*] --> Pending

    state Pending{
         
         [*] --> GenericCleaning: Mode - UpdateFromSharingMember

        state GenericCleaning{
            [*] --> GenericCleaningQueued
            GenericCleaningQueued --> GenericCleaningReserved
            GenericCleaningReserved --> [*]
        }

        GenericCleaning --> BpnProcessing

        state BpnProcessing{
            [*] --> BpnProcessingQueued
            BpnProcessingQueued --> BpnProcessingReserved
            BpnProcessingReserved --> [*]
        }

        BpnProcessing --> [*]

        [*] --> GoldenRecordUpdate: Mode - UpdateFromPool
        
        state GoldenRecordUpdate{
            [*] --> GoldenRecordUpdateQueued
            GoldenRecordUpdateQueued --> GoldenRecordUpdateReserved
            GoldenRecordUpdateReserved --> [*]
        }

        GoldenRecordUpdate --> [*]

    }

    Pending --> Success: if finished
    Pending --> Error: if disrupted by error

    Success --> [*]
    Error --> [*]

Loading

---
title: Cleaning Task Composition
---
classDiagram
    
   class CleaningTask{
        Task Identifier: String
        Generic Business Partner: Object
        Legal Entity: Object
        Site: Object
        Address: Object
   }

   class TaskState{
        Result State: ResultStateEnum
        CreatedAt: Timestamp
        ModifiedAt: Timestamp 
   }

   class ResultState{
        <<enum>>
        Pending
        Success
        Error
   }

   class StepState{
        CreatedAt: Timestamp
   }

   class CleaningStep{
        <<enum>>
        GenericCleaning
        BpnProcessing
        GoldenRecordUpdate
   }

   class ReservationState{
        <<enum>>
        Queued
        Reserved
   }

    StepState "1" --> "1" CleaningStep: CleaningStep
    StepState "1" --> "1" ReservationState: ReservationState

    TaskState "1" --> "*" StepState: StepHistory
    TaskState "1" --> "1" ResultState: ResultState

    CleaningTask "1" --> "1" TaskState: State

Loading

Note: The naming of the fields and classes are just proposals and can be decided by the implementor

Tasks

• Create cleaning task class model
• Create service logic to save business partner data and perform state transition
• Create service logic to query cleaning tasks based on state
• Connect service logic with Orchestrator endpoints

Dependencies
#426
#425
#388
#392
#377

[martinfkaeser]

Proposition:
When creating a new cleaning task the Gate sets the TaskMode, e.g. UpdateFromSharingMember or UpdateFromPool.
On the basis of the mode the Orchestrator determines the necessary steps, e.g.

• UpdateFromSharingMember -> FullCleaning, PoolUpdate
• UpdateFromPool -> LightCleaning (or EcoCleaning ;-) )

For each step the Orchestrator goes through the states Queued and Processing. After all steps have finished it goes to state Finished. After the task output has been retrieved the task is completely removed.

[gerlitmcoding]

Maybe you could call the "light cleaning" -> GrSync

[nicoprow]

Proposition: When creating a new cleaning task the Gate sets the TaskMode, e.g. UpdateFromSharingMember or UpdateFromPool. On the basis of the mode the Orchestrator determines the necessary steps, e.g.

* `UpdateFromSharingMember` -> `FullCleaning`, `PoolUpdate`

* `UpdateFromPool` -> `LightCleaning` (or EcoCleaning ;-) )

For each step the Orchestrator goes through the states Queued and Processing. After all steps have finished it goes to state Finished. After the task output has been retrieved the task is completely removed.

I'm overtaking the idea for renaming the modes:

UpdateFromSharingMember and UpdateFromPool

The cleaning step names I'm undecided about

[nicoprow]

How about
GenericCleaning -> 'CleanAndSync'
BpnProcessing -> 'PoolSync' (or GoldenRecordSync as proposed by @gerlitmcoding )
GoldenRecordUpdate -> 'Clean'

I think this fleshes out more the distinction between the cleaning steps, as in the 'CleanAndSync' record needs to be cleaned and also the record data may change the resulting golden record. In 'Clean' the record us just cleaned and no change to the golden record is done.

[gerlitmcoding]

@nicoprow In which usecase/scenario would you use/need the only clean state?

[mknoopvw]

@gerlitmcoding I have no idea why you are asking me? Nor can I answer this question.

[gerlitmcoding]

@gerlitmcoding I have no idea why you are asking me? Nor can I answer this question.

Sorry, that was a wrong autocompletion 🙈

[nicoprow]

@nicoprow In which usecase/scenario would you use/need the only clean state?

@gerlitmcoding
This the golden record process step for when there was an update on the Pool and the respective records in the Gate need to be adapted to the newest golden record.

Mode - UpdateFromPool

[martinfkaeser]

Duration implementation some questions came up:

1. For how long do we keep the business partners stored in the orchestrator?
   There is no resolve call from the Task Client that could be used to delete them.
   My idea would be that we define a taskStorageTimeout that starts ticking when the Task Client posts a BP.
   We could return this timeout in the response, similar to taskReservationTimeout.
   This is maybe not needed yet in the first version, but it makes sense to specify it.

2. I'm thinking about extending the StepState.
   If an error occured during task processing or all went through okay, the specified states Queued and Reserved seem confusing and inadequate when retrieving task states.
   For clarification we might add states Success and Error.

3. Do we need a StepHistory inside the Orchestrator although only one step and stepState is returned by the API?
   It might make sense for a later version of the API for keeping track of the time spent in the steps/states.
   In this case the suggested states Success and Error make even more sense: It might be interesting how long processing took (time between Reserved and Success).
   But I would suggest keeping the internal state aligned with the API and not managing a StepHistory for now.

@nicoprow What's your opinion?