Choose a transformation approach

Stedi supports three ways to transform transaction data to and from Guide JSON format: Stedi Mappings, writing custom code, and using an iPaaS platform.

The approach you choose depends on your circumstances and preferences.

​

Stedi Mappings

Stedi Mappings is a powerful JSON-to-JSON transformation engine. You can build mappings using Stedi’s visual mapper and use mappings to transform data for both inbound and outbound transactions.

• Inbound transactions: Configure Destination webhooks to deliver the transaction data directly to your API. Add a mapping to transform the transaction into your system’s format before delivery.
• Outbound transactions: First, call the Invoke Mapping API from your codebase to transform your system’s data into Guide JSON. Then, use the transformed payload to construct a call to the Generate EDI API.

​

When to use

We recommend using Stedi Mappings when:

• Your system can natively produce and consume JSON payloads. Mappings is designed to map one JSON shape to another JSON shape. If your system uses another format like XML or CSV, Mappings isn’t a fit.

• You plan to do one-step transformations without multi-step processing. For example, you need to reshape a Guide JSON payload to post to a simple API endpoint.

• You want your business or operations team to manage mappings. The first few mappings typically require an engineer and often some pairing help from Stedi’s Customer Success team. Once you build a few examples, business users can often edit, maintain, and build mappings independently.

• You want a solution that’s integrated with the Stedi platform. Stedi’s Mappings product is integrated with Stedi Guides, making it easier to build mappings from any Guide JSON Schema and test mappings using sample Guide JSON payloads. You can also control which users can view, edit, and deploy mappings with Role-Based Access Control (RBAC).

​

Cons

We don’t recommend using Mappings alone to build the end-to-end functionality for use cases requiring dynamic lookups or multi-step processing.

In many integrations, you need to translate Guide JSON into your system’s API shape and then dynamically look up internal IDs from a constantly-changing list. For example, you might need to call out to an ERP or API to look up a customer’s ID and use that information to replace values in the JSON object before posting to an API.

To accomplish this flow, you would need to first transform the Guide JSON into your system’s API shape using Mappings and then use your own codebase or iPaaS platform to perform the lookups and replace the values. This is a viable option, but the approach requires maintaining the transformation steps in two separate systems – the field mappings in Stedi’s Mapping product, and the dynamic lookups in custom code or an iPaaS platform. If you prefer to keep all of your logic in one place, you can do all of the transformations in your own codebase or an iPaaS platform, without using Stedi Mappings.

​

Custom code

You receive transaction data from Stedi in Guide JSON format. You write the required logic to transform Guide JSON to your preferred format and run it on your infrastructure.

• Inbound transactions: Configure Destination webhooks](/edi-platform/configure/destinations/index) to deliver the transaction to your system as-is. Your transformation code will map that payload into your system’s format and deliver it to the ultimate destination.
• Outbound transactions: Transform your system’s data into Guide JSON and call the Generate EDI API directly.

​

When to use

We recommend writing custom transformation code when:

• You want to manage data transformations and business logic in your own codebase. For example, you want to write tests and and deploy changes using your existing CI/CD pipeline.

• You only need a small number of mappings that won’t change very often. For example, a large retailer may use a single 850 Purchase Order guide for all of their suppliers and create a single mapping that transforms their internal API format into the 850 Guide JSON format.

• You can have engineers involved in every mapping change. Engineers will need to make the changes and ensure that every change is well-tested and deployed in a controlled manner.

• You need to perform complex lookups or multi-step processing. For example, you need to dynamically replace values in the JSON object prior to posting to your API.

​

Cons

Coding your own mappings can be cumbersome when you need to build more than a few mappings or your mappings change frequently. For example, a logistics platform may need to support hundreds of different 204 Load Tender formats from different carriers, each with their own mapping.

Generating and maintaining many custom mappings usually requires a lot of coordination between business and engineering teams, which can lead to delays in getting new mappings into production.

​

iPaaS platforms

iPaaS platforms like Workato or Tray.io are purpose-built to allow non-engineers to integrate and automate business processes. Just like you can use an iPaaS platform to integrate your ERP or custom system with Salesforce or Shopify, you can use an iPaaS platform to integrate your system with Stedi.

• Inbound transactions: Configure Destination webhooks to trigger a workflow run. The workflow should transform the Guide JSON into your system’s format and then use a pre-built or custom connector to deliver the transformed payload to your system.
• Outbound transactions: You can use the iPaaS platform’s built-in functionality to map your system’s data into Guide JSON, and then use the iPaaS platform’s pre-built HTTP connector to call the Generate EDI API with the transformed payload.

​

When to use

We recommend using an iPaaS platform when:

• You want to leverage iPaaS functionality. iPaaS platforms offer a wide variety of functionality that is useful for integration scenarios, such as a graphical interface to build integration flows, pre-built connectors, support for API creation and management, data mapping tools, and the ability to orchestrate complex integration scenarios involving multiple endpoints.
• You’re already using an off-the-shelf business system (such as a CRM, ERP, or TMS) that is supported by the iPaaS platform.
• You want to build and maintain EDI integrations without involving engineers.

​

Cons

• You need a separate subscription to an iPaaS platform, which incurs an additional cost. However, this approach often ultimately reduces costs over time because you don’t need engineers to build or maintain your integrations.

• You will need to keep your mapping shape definitions in sync between Stedi and the iPaaS platform. For example, if you update a Stedi Guide to include a new field, you must 1) update any mappings that use the new field and then 2) update the schema in the iPaaS platform. These duplicate updates can be cumbersome and lead to processing errors if not completed in sync.

  If your iPaaS platform supports JSON Schema, you can export the Guide JSON Schema from Stedi and import it to your iPaaS platform. This approach allows you to use the iPaaS platform’s built-in data mapping tools to map your system’s data into Guide JSON and will make it easier to update the schema as it changes.