Release date: 03/25/2021

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.

Release date: 04/06/2021

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.

More details on these articles: What is Integration Assistance?

Release date: 03/18/2021

Overview: Updated design of the Rules Editor.

Purpose: Same functionality, better experience.

Release date: 03/18/2021

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:

Release date: 03/09/2021

Overview: Email notifications for any change of a transaction's validation status, delivery status, or acknowledgment status.

Purpose: Provide an easy and consistent way to subscribe to notifications related to your transactions.

Your subscriptions to email notifications can be managed on the Notifications Settings page.

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.

We’re excited to announce an update to our API.

Release date: Feb 9th, 2021

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:

"message": { 
    "content": {...}, 
    "validationStatus: "VALID", 
    "sizeInBytes": 3251, 
}

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:

"revisions": {
    "original": { 
        "content": "https://api.orderful.com/v3/transactions/123/content", 
        "validationStatus: "VALID", 
        "sizeInBytes": 3251, 
    },
     "latest": { 
        "content": "https://api.orderful.com/v3/transactions/123/content", 
        "validationStatus: "VALID", 
        "sizeInBytes": 3251, 
    },
}

Calling the content link will return you the content in its present JSON form:

content-type:application/json 
{  
    "transactionSets": [{
    ...
    }] 
}

And in the future, in newly-supported data types:

content-type: text/csv
invoiceNumber,456
invoiceDate,03MAR2021

More details can be found in the API reference documentation.

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:

"message": {
		"content": {...},
		"validationStatus: "VALID",
		"sizeInBytes": 3251,
	},

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:

"message": {
		"content": "https://api.orderful.com/v3/transactions/123/content",
		"validationStatus: "VALID",
		"sizeInBytes": 3251,
	},

Calling the content link will return you the content in its present JSON form:

content-type:application/json
{
  "transactionSets": [{...}]
}

And in the future, in newly-supported data types:

content-type: text/csv

invoiceNumber,456
invoiceDate,03MAR2021

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.

More details in these articles: