The following describes how Logixboard uses the eAdapter, "Z" events, & workflow templates.
eAdaptor Inbound
eAdaptor Inbound is the mechanism by which CargoWise One (CW1) accepts messages. WiseTech calls this "Inbound" because, from the CW1 perspective, messages are coming inbound to them.
How Logixboard uses it
Today, Logixboard (LXB) uses eAdaptor Inbound to both fetch information from CW1 and write information back to CW1. This happens when we first onboard the tenant to backfill historical information, and also happens periodically as part of regular operations. For example, a user can upload a document using Logixboard, and this document is posted to CW1 eDocs.
eAdaptor Outbound
eAdaptor Outbound is how CW1 notifies our system of things that happen in "real time."
How Logixboard uses it
Logixboard uses eAdaptor Outbound to get notified of changes to relevant jobs, such as when new jobs are created in CW1 or when updates to existing jobs are saved. For example, every time a Shipment is created or edited in CW1, Logixboard receives updated data about the Shipment via eAdaptor outbound. This mechanism is also utilized to receive data about Events of interest. For example, when a Shipment departs from the origin port, CW1 sends an Event message to Logixboard via eAdaptor Outbound.
Custom "Z" Events
Our implementation of a custom "Z" event (by default, Z87) is used as a workaround for CW1 limitations in returning data via eAdaptor Inbound. Logixboard tries to maintain data transfer as close to real-time as possible, and there are cases where CW1 sends us an event and we need to retrieve the full Universal Shipment file to get the full context on the changes.
There are two ways that we can request the full file from CW1:
Via eAdaptor Inbound by querying for a specific file
Via eAdaptor Outbound through an event that will push the full file to us
We have observed significant instability in eAdaptor Inbound at high volumes, which leads to data transfer failures and therefore out of sync files on the Logixboard side. Our workaround for this instability is to utilize a custom "Z" event, which is posted to a job after the Logixboard system receives certain events from CW1. This ensures we have the latest data from CW1, since posting the Z event will return a full Universal Shipment file from eAdaptor Outbound.
Workflow Templates
Logixboard uses a number of constantly evolving workflow templates (WFTs) to ensure we receive data for all of the different modules and events we support. There are a large number of triggers on these templates. Below is a list of the templates, if you need more information please reach out to [email protected].
💡 It is highly recommended that you install these templates on a training environment and not production as they can trigger a high volume of outbound messages.
🛠️ ⛔ Do not modify Logixboard-installed workflow templates without consulting your CSM or Logixboard Support. Improper modification of LXB WFTs can result in data integrity issues, misrouted messages, and other severe interface problems.
Workflow Template XMLs Forwarding Orders
Brokerage
Consols
US ISF
Organization
Receivables Transactions
Sailing Schedules
Shipments
Staff and Resources
Sequence
Logixboard workflow templates are installed with a trigger sequence of 9999 so that LXB triggers are placed at the bottom of the list on each job to minimize interference with daily operations.
Workflow Template Start Dates & Data Backfills
There are two primary mechanisms to ensure Logixboard does not pull old data when it is not necessary or desirable:
Limiting initial backfill: When data is backfilled during onboarding, we can limit to a specified date range based on the "Created At" timestamp within CW1.
Adding WFT start dates: To preclude Logixboard WFTs from being applied to older jobs, we can add start dates to the WFTs. The combination of limited backfill and WFT start dates ensures that older jobs do not propagate into the Logixboard system.
Message Forwarding ("Republishing")
CW1 has an eAdaptor Outbound limitation where only one outbound connection is allowed at a time. To overcome this limitation, Logixboard offers a lightweight message forwarding service (a "republisher") which allows you to continue to push outbound messaging to another service while integrated with LXB.
We support republishing to one other partner and will filter out all Logixboard messages. To differentiate our messages from other messages, Logixboard messages use a "LXB" prefix on the trigger descriptions, as well as a custom LXB Purpose Code in the EDI comms. Organization Proxies are also configured such that Logixboard messages have LOGIXBOARD as the recipient.
Middleware Requirements
For partners already utilizing a middleware service for message republishing, the following requirements must be met for successful LXB integration:
Message Format: Logixboard expects messages in the same format as what CW1 would provide - a SOAP-wrapped XML, where the XML is gZipped and base-64 encoded. Message batching within a single envelope is supported, just as CW1 does. Your Technical Onboarding lead will provide the API endpoint to which these messages should be published.
Message Identifiers: CW1 provides a unique eHub ID for every individual XML message included / embedded in the SOAP wrapper. Each message forwarded to LXB must also have a unique identifier - preferably the eHub ID provided by CW1.
Message Volume & Timing: Due to the near-real-time nature of the LXB integration, message volumes out of CW1 can be extremely high (up to several thousand messages per hour). The middleware service must be able to sustain these message volumes in near-real time (under 5m delay), as CW1 does.
Message Order: The CW1 Log Walker Service queues and sends messages in first-in-first-out (FIFO) format. Middleware republishing to LXB must also be FIFO, as order of events is extremely important to the LXB integration.
Message Sources: LXB WFTs are global, meaning they apply to all Companies within CW1. Middleware republishing services must send messages from all CW1 Companies to LXB to ensure we receive all relevant updates.