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: 

• Access Relationships
• Search Relationships

We’re excited to announce a new endpoint to get your Organization details.

Release date: 12/24/2020

Overview: New endpoint to get IDs related to your organization.

Purpose: When starting your integration to Orderful, you can call this new endpoint with your API Key to ensure you're connected to the right organization and to retrieve the important IDs that are part of your organization.

The endpoint is documented in our API reference.

Next up in Orderful is the ability to assign guidelines to relationships!

In the past, every organization is Orderful was allowed to have only a single guideline per transaction type, which was applied to all your relationships with matching transaction type and direction.

Going forward, an organization can have many published guidelines of the same type, that are then assignable to a relationship. The process of creating a guideline remains unchanged:

• Go to the Guidelines settings page.
• Click "Create Guideline".
• Enter your guideline in draft mode.
• Publish the guideline when it's ready.

Published guidelines are not automatically enforced on your relationships. Instead, published guidelines are assignable to relationships, under relationship settings.

Once assigned, a guideline is used to validate data flowing through the relationship. For more information about guidelines, please see our Knowledge Base.

We are excited to release another improvement to our platform: Poller communication channels!

When you create a Poller communication channel, Orderful will generate a new API endpoint that you can use to retrieve your transactions. Along with this improvement comes the ability to resend inbound transactions from the UI and to confirm a transaction's delivery using our API.

You can see the API documentation here: https://docs.orderful.com/reference/pollingcontroller_list

For step-by-step instructions on how to set this up, please see here:

• For Followers: https://docs.orderful.com/docs/set-up-org-follower#inbound-poller
• For Leaders: https://docs.orderful.com/docs/set-up-org-leader#inbound-poller

We're excited to launch a new feature in Orderful: Communication Channel Testing.

For each inbound HTTP or AS2 Communication Channel connected to your internal systems, you can now directly send a test file over and check the connection is up and running.

Send a test to a Communication Channel

From the right side panel of an inbound Communication Channel, you now have the option to "Send a test". You can choose to send one of the generic Orderful test files or upload your own custom test file.

Orderful then displays a test summary that contains:

• The test status
• The test file you sent
• The delivery proofs (if any)
• The delivery logs

Test an HTTP Communication Channel

When testing an HTTP Communication Channel:

• The test status can only be “Delivered”, “Failed” or “Timed-out”.
• The HTTP response code appears on the “Log” row.
• The full HTTP Response is stored as a file on the Received row.

Test an AS2 Communication Channel

When testing an AS2 Communication Channel:

• The test status is “Pending” until your AS2 server sends a final successful or failed delivery notification. The test status then becomes “Delivered”, “Failed” or “Timed-out”.
• The Message Disposition Notification (MDN) is stored as a file on the Received row.
• The “Log” row displays all delivery notifications received.