The MSPro Boomi Collection
About
Good Practices & Patterns
Good Practices & Patterns
  • Markus' Boomi Integration
  • Implementation Patterns
    • The Cache Challenge
      • The Get-Or-Create Use-Case
      • PropCache Scripts
    • State Management
      • Example Scenario
      • State-Management in general
      • State-Management Functionality
      • Technical Solutions
        • Boomi File-System Implementation
          • saveState
          • readState & fetchStates
    • Exception Handling
      • Exception vs Error
      • Basic Rules
        • Aggregating Exceptions
      • Exception Handling Pattern
        • User-Defined Exception Messages
        • Catch Exceptions
      • The pattern in practice
        • API Error Handling
          • Single Record Strategy
            • Single Record RES
          • Many Records Strategy (Array)
            • Many Records RES
        • Pre-Condition Check
    • SQL Patterns
      • Script Header
      • General Rules
        • Check using RowCount
        • Check if record exists
        • Pagination and Sorting
        • Parameter - Best Practices
        • Use JSON as a complex parameter
    • Process Patterns
      • Process Route Implementation Pattern
      • Sub-Process or Process Route
    • DateTime
      • The Boomi datetime dilemma
      • Database and Flow
      • Groovy
      • Data Hub
      • Get Current Date
    • Groovy Script Patterns
      • Dynamic Document Properties
      • Dynamic Process Properties
      • Documents
    • Array Elements to Documents
  • MSPro Services
    • Intermediate Storage
      • Example Processes
        • Docs 01 - Update and Create
          • sub.SampleData.Invoice
        • 02 - Upsert and Get
    • Render Templates
  • Tips
Powered by GitBook
On this page
  1. Implementation Patterns
  2. State Management

State-Management in general

Last updated 6 months ago

What I am going to describe in this chapter is about State-Management in general. I am deliberately leaving out a technical solution.

Let's think about a couple of scenarios that come to our mind when think about states.

  • We must keep the received data in its original form in order to be able to refer to the received record at any time: payload.

    • Of course, the payload has a payload-type.

We must be able to reference the received records in the source system and we expect that each received record comes with a unique identifier from the source system.

  • The userId contains the source system record id.

When a state-record has been created systems must be able to access the state record using a unique identifier.

  • The id is a unique id for each state (requestId).

Normally, different customers send data from different sources, using several channels and we must track the origin of each state-record.

  • The generic context is used to track the records origin.

It is probably a good idea to give a state some kind of name that contains information about which (business) state is involved.

  • A key is a well defined name/key for each state.

    • Keys can contain namespaces, like: CustomerA.Offer to indicate that this state is an offer from customer A.

Last but not least, we want to track a state.

  • userState contains the state of the record, and

  • userInfo can contain any user-defined (error) message for the current state. The userInfo may contain a simple text message, as well as a structured, additional information, like a JSON record, to track additional metadata for each state. This field is always custom and its information is fully transparent for the state-management.

More considerations

Further considerations, not detailed here, could be:

  • state-lifetime -> expiration date

  • track a records state history

j.State - a State profile as it can be used in Boomi