2026-01-01 - Integrating Izara Commerce with Supply and Market

Development - Izara Commerce

Development - Izara Supply

Development - Izara Market

Development - Izara Accounting

Overview

Izara Commerce, Izara Supply and Izara Market are three standalone projects, however we want them to integrate together.

Can use in all projects, eg Market connecting to Supply, Commerce connecting to Accounting.

Examples:

• If attributes or stock changes for an inventory item in Commerce, a product/selloffer in Market get updated
• If an order is made on Market a customer and sale are created in Commerce
• If an inventory attribute is changed in Commerce a Stage is created in Supply
• If production happens in Commerce a Transform process is created in Supply (maybe also bundling/un-bundling between inventory item/s)

Idea

objTypes in Commerce can attach plugins that integrate with external services, for example a plugin can be attached to goods that connects to Market and creates data managing the connection. Another plugin can be added to the good to integrate with Supply

Have hooks in all logic that enter into the plugin to perform actions.

Each plugin has a list of which hooks it attaches, so only invoke when needed.

structures

plugInTag

• identifies a plugin (stand alone project)

plugInHookTag

• tag for one location in flow code where plugins can be invoked
• is located inside flowStep within a flow

plugInHookTagId

• identifies a plugInHook including which flow and flowStep it belongs to
• serviceTag_flowTag_flowStepTag_plugInHookTag

Reorganizing schemas and generated code for Plugins

Plugin registrar

• Each project has a registrar of available plugins and their configuration
• each plugIn has a fixed plugInTag
• Config lists which pluginHooks the plugin connects with and whether those plugInHooks are sync or async
• Config lists which permissions are required, this allows plugins to perform actions on behalf on a user (or perhaps other target/belongsTo Id)

plugInTag types

• available plugInTag and their configs are a per project configuration, maybe handled as an npm library?
• plugIns are identified by plugInTag
• plugIn config specifies connected objType
• plugIn config lists which plugInHookTagIds it hooks into (so when a flow finds a connected plugIn it can check should invoke?)
• plugIns are connected to instances of the objType, identifiers are automatically sent when invoking plugIn endpoints

examples:

• eg: a user in Izara Commerce can connect a Business instance with comAcc which also connects to an Organization instance in Izara Accounting
• eg: a user in Izara Market may attach Izara Supply to a sellOffer, logic that works on that sellOffer will trigger plugInHooks that update Supply

special case: base user plugIns vs submittedBy plugIns

• eg: a user in Izara Commerce may attach an Agent plugIn to their userid, any logic where they are the signed in user for other user accounts will trigger plugInHooks
• perhaps both types of plugIns connect to objType user, but have different hooks for when base user has attached plugIn or when submittedBy user has attached plugIn

Attaching plugIns to object instances

• plugIn registrar separates available plugIns according to what objType they connect to
• service that is responsible for the plugInTag/plugInHookTag objType has a dynamo table of connections, partition key is identifier concat for an objType instance, sortKey is plugInTag

All Lambdas are generated

• each flowStep in flowSchema lists it's plugInHooks in an ordered list so code generation can create code for processing plugInHooks
• All lambdas in a flow are generated including their handlers
• Generated code auto-generates processing of plugInHooks, including identifiers and other params
• developer geneerated code hooks are responsible for delivering correct variables to code blocks that process plugInHooks
• each plugInHook in schema has a normalized list of the params it sends out (used in generated code, and perhaps notifications)
• to isolate the required params maybe use a specific object as the param for processing plugInHooks, with object properties matching required params
• eg: for base user or submitted user the param object will have the same param/obect properties, but the variable used will differ (which userId)

• other flow code such as storedCache/triggeredCache can be added when generating the flows Lambda functions

Generating Lambdas according to plugInHooks

• plugInHooks may be invoked sync or async, if async then remaining code must be a separate Lambda
• each plugInHook that plugIns can connect to might have multiple plugIns connecting to them, these may be sync or async
• simplist way to manage this is to separate code at each plugInHook into different Lambdas
• generate code at each hook checks connected plugIns, if have sync then process immediately, if async create awaitingMultipleSteps and send them off
• if no async then invoke next Lambda, eg by DSQ
• if async then have am in SNS handler that receives complete messages from plugIn that checks awaitingMultipleSteps and continues to same DSQ Lambda

Seperating flowSteps into Lambdas

• because there will be multiple Lambdas auto generated for each flowStep need to list the subSteps in the flowStep schema
• maybe bump up to flowStep, so one flowStep is one lambda
• maybe move event/?output into each step
• consider other separations of logic, such as awaitingStep/awaitingMultipleSteps/pagination/logic in other generated code such as CreateObject

folder structure

• similar to generated code
• each flowType has it's own folder
• each flowStep has a child folder under flowType
• each Lambda in a flowStep has a child folder under flowStep
• each Lamdbda has the generated template, developer code hooks, and final generated code

code and plugInHooks in old generated code

• Generated code such as createObject old code has hooks (developer code) according to objType, sometimes this is sync and sometimes async
• Can use similar structure of splitting that code into Lambdas according to codeHooks/plugInHooks

This will add another level to generated code

• generate code template with top level generated plugInHooks/codeHooks
• flowSteps then take over the top level codeHooks with generated code that has flow level codeHooks and plugInHooks
• both of these steps will create multiple Lambdas according to the hooks they offer
• do we have flowSchemas for generated flows like createObject yet?

Idea

• flowSteps can only add hooks to objType generated code in it's own service
• when generating objType generated code check all flow schemas in service to see if any add logic in the generated flow
• adjust the objType generated code accordingly, this may mean additional Lambdas according to the flowStep config

authentication

• each plugInConnectionId (concat identifier with plugInTag) could have it's own authentication process, eg access key
• this would allow the business/organization to specify which permissions are allowed per connection (although for the plugIn to function really all necessary permissions should be allowed)
• alternatively a user could enable the plugin on their account with authentication id, and all objType instances use that access key
• example Connection per Inventory plugIn connections to Amazon PlugIn, not need to authenticate per Inventory, authenticate per Business and all inventory use that authentication, even though the connection is per Inventory instance

• Each project has RBAC where multiple users can control an user/business/organization data.
• When plugIns connect to data, use the plugIn's permissions rather than the user that initiated the action
• Each project manages whether user permissions allow a user to initiate the action, but once it passes to the plugIn it is the plugIns permission that is used

• can do complex authentication flow later, for now if user connects plugIn it will have access
• but we probably need a special userId for flows that eg check userLevel rbac
• perhaps plugInTag could be used as userid, maybe adding prefix that can be checked by permission handler so always passes?
• however pages that must be signed in might not work, maybe need to access key to ensure the request from plugIn was authorized