Overview: When resending an inbound transaction to your communication channel, you now have two options:
Send: Resend the transaction with the exact same payload as before
Reprocess and send: Apply any rules changes, revalidate it against your inbound guideline (if applicable), and send.
Purpose: If your backend rejects an inbound transaction because of a rule issue, you can now fix the appropriate relationship rules, apply them to the transaction, and resend the transaction without having create a new copy.
You'll notice that clicking the Send button at the top right of a Transaction details page now opens a drop down with the two options.
Overview:New Integration Assistance page to help you build your connector by understanding the JSON transaction payload and the associated leader’s requirements.
Purpose: On your new Integration Assistance page, you can select one or several relationships to generate a transaction payload that respects the leader’s guidelines. You can also access granular guideline requirements for each property of the transaction payload.
A relationship is composed of two partners - a sender and a receiver - and a transaction type.
In each relationship, one partner is the leader and the other partner is a follower.
Leaders define and assign guideline and scenario requirements that the follower must respect.
When building a connector for a transaction type, you must respect the leader’s guideline requirements when mapping your transaction payload to your ERP or SOR data:
If you’re a Leader, you should map the transaction payload to your requirements.
If you’re a Follower, you should map the transaction payload to all your leader’s requirements.
The Integration Assistance helps you build your connector mapping for a specific transaction type according to the leader’s requirements by allowing you to:
Generate a transaction payload in JSON for specific relationships of the same transaction type.
Access the leader’s guideline requirements for each property and array of the transaction payload.
Overview: Added optional 'note' property to Confirm Delivery endpoint for your backend to post delivery notes back to Orderful. These notes are added to the transaction's audit trail.
Purpose: Your ERP can now include a delivery 'note' when confirming the delivery of a transaction. This note will be added to the transaction's audit trail for your reference.
For more information about this new feature, please see this article:
When subscribed to an email notification, Orderful will send you an email every time a transaction meets the status requirement of the notification (e.g. delivery status = failed).
We’re excited to announce the next improvement to our platform. Data format on relationships!
Release date: 02/18/2021
Overview: Data format toggle migrated from Communication Channels to Relationships.
Purpose: You can now specify your desired data format on a per-relationship basis.
After analyzing the way our customers trade JSON and X12 data, we decided to move the data format toggle from Communication Channels, on to Relationships. This makes it easier for you to handle your data formats on a per-relationship basis, independently of that of your trading partner.
You'll notice the data format toggle on top of the relationship's side panel.
We’re excited to announce a new improvement when sending a transaction to a communication channel.
Release date: Released on 02/17/2021
Overview: Standardize our retry system when sending a transaction to a communication channel
Purpose: Orderful now retries sending a transaction to a communication channels 3 times before moving the transaction to the Failed delivery status.
To make sure a delivery failure isn't related to a server temporary issue, Orderful now retries sending a transaction to a communication channels 3 times:
1st retry: 5 min after the initial delivery failure
2nd retry: 10 min after a delivery failure on the 1st retry
3rd retry: 20 min after a delivery failure on the 2nd retry
Each delivery failure or success on retries are captured on the audit trail.
A delivery failure on the 3rd retry moves the transaction to the Failed delivery status.
📘
Orderful retries to send a transaction when the delivery failure isn't tagged as permanent.
Overview: Change of a property on the GET /v3/transactions/:id endpoint
Purpose: In order to future proof an endpoint before anyone integrates to it we've added more functionality when retrieving a transaction.
This change comes with a helping of humility as we're doing something we said we wouldn't: making a breaking change to an API endpoint. After some future planning we've realized a recently released endpoint could be made more future-proof with a small modification. The only reason it's acceptable to make a breaking change is that our operational analytics indicate that no one has integrated to the endpoint yet. There are occasional test requests but no production loads relying on it.
The Change
If you recall the GET /v3/transactions/:id response payload you'll recall the message property currently looks like this:
Here the content is a JSON object. While this covers today's use cases, we're currently designing out non-JSON payload support (e.g. XML, CSV, etc) – which obviously could not be returned as a JSON object. Also for future non-JSON payload you'll need to be able to access the original payload before conversion and the latest one after.
The path forward is to maintain our JSON-first API but separate the content out into its own endpoint which can support any content type. Now the message portion will be renamed to revisions and support both the transaction as posted and after processing. The property will now look like this:
This change comes with a helping of humility. We're making a breaking change to an API endpoint. After some future planning we've realized a recently released endpoint could be made more future-proof with a small modification. The only reason it's acceptable to make a breaking change is that our operational analytics indicate that no one has integrated to the endpoint yet. There are occasional test requests but no production loads relying on it.
The Change
If you recall the GET /v3/transactions/:id response payload you'll recall the message property currently looks like this:
Here the content is a JSON object. While this covers today's use cases, we're currently designing out non-JSON payload support (e.g. XML, CSV, etc) – which obviously could not be returned as a JSON object.
The path forward is to maintain our JSON-first API but separate the content out into its own endpoint which can support any format. Now the message portion of the GET /v3/transactions/:id response will look like this:
We’re excited to announce a new interface for the Relationships page.
Release date: Released on 02/08/2021
Overview: New filters, sorting and search capabilities on your Relationships page.
Purpose: On your Relationships page, you can find relationships by using one or several filters, entering one or several keywords in the search bar and by sorting a relationship column.
After analyzing user feedback on the Relationships page, we decided to improve your Relationships page for several reasons:
We moved away from grouping relationships by EDI accounts to display all relationships in a table view. When combining one or several filters and a table view, you can now find your relationships quicker.
We introduced new columns to display more key information about your relationships, such as your EDI account names and ISA IDs as well as your partner's.
We improved our search bar so that you can look for more information at the same time.
We added a sort functionality to the relationships columns to help you order your relationships according to what's more important for you.