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. The Cache Challenge

The Get-Or-Create Use-Case

Last updated 4 months ago

Get-Or-Create is a very common use case.

The client sends invoices with an accountNo (number). Your process must check if the accountNo exists and get the account's id, or it creates a new account for the given number. In any case, the process needs the internal accountId (record-id) to continue processing the invoice: createInvoice( invoiceNo, accountId)

AccountNo --> get (accountNo) 
              :ok                           --> accountId
              :failed--> create (accountNo) --> accountId

If you consider an input profile like this: j.Invoice.REQ

{
    "InvoiceNo": "I003-3",
    "AccountNo": "ACC009",
    "ToalAmount": 2300,
    "InvoiceDate": "2024-02-28"
}

You will notice that having the acountId as a Dynamic Document Property attached to the document would be a perfect solution, to create an Invoice: DDP_AccountId = 69d38081-3c43-41f8-b3d7-34cb9516eefe

Unfortunately the implementation is not as easy as it seems, and the proposed solution won't work: the reason is that at the end of Branch 1 the account response incl. the accountId are discarded and they are no longer available on the beginning of Branch 2 where you need the accountId to create the invoice.The Cache Challenge.

if you then need the created invoice's id, too, for the j.Invoice.RES response, you are into trouble. The solution follows: PropCache Scripts

Proposed solution