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

State Management

Last updated 6 months ago

Many data integration scenarios cannot simply transfer data from A to B in a stateless and synchronous manner. Very often, the received data must go through a technical or business process before an incoming data record can be marked as successfully processed. In addition, data records are often delivered as a batch or as a CSV file, and each individual data record then has its own status. Last but not least, the Customer wants to know about the success or failure of each record to be able to fix and resend records which not reach the target.

The status of each record must be tracked so that the state of the processing can be seen at all times.

State vs. Status

I distinguish between State and Status.

State refers to a record's state, where Status may contain additional information about a specific State: Status = State Reason.

For example: State = DELETED, Status=MANUAL | BY_SOFTWARE.

Example Scenario
Transfer data from A to B in multiple steps, maintaining a State