Supplier Technical Integration Strategies

Introduction

Add more later

General Rollout Strategy

Most Suppliers start with simpler API’s and work towards increased complexity on either the transaction side or the product data side - for example:

Transactional Path:

Non-Transactional Path:

These paths will give a good walkthrough of the easier API’s - they both ultimately wind up needing Price & Config before PO and then PO to actually submit PO’s. Price & Config is widely regarded as the most difficult of the API’s to create.

It is strongly recommended that new API’s are “soft released” to specifically selected Distributors who will provide good feedback on the implementation before publishing the release of the endpoint on PromoStandards.org. This will provide invaluable user-acceptance testing feedback before opening the endpoint to the world.

It is also strongly recommended that a Supplier rolling out API’s for the first time progressively enable new accounts; enable a few accounts, measure performance, enable some more, measure again.

Integration Considerations

Many of the topics below are not specifically about PromoStandards per se, but they are worth repeating here in a “PromoStandards Context” as they touch on challenges that have been encountered with PromoStandards integrations.

Sizing The Technology

PromoStandards API call responses can get fairly verbose. As a result, pay attention to what will be the maximal response payload size when selecting an implementation technology - and there’s no “golden rule” because the amount of data passed back can be greatly affected by how and what a Supplier sells, for example:

• getProduct() call responses will vary significantly depending on if a Supplier sells cups in one or two colors versus apparel in ten sizes with eighty colors

• getInvoices() with a date range may vary significantly depending on how a Supplier invoices orders (per PO, rolled up within a certain criteria, etc…)

If a Supplier’s catalog is large with verbose descriptions, if a Supplier invoices per PO, response payloads might easily go over the 10-15 megabyte constraints in place for many Lambda function offerings and API gateways. Spend some time early in the process assessing maximal payloads before choosing a technology. Do not rely on “trimming back data” or being increasingly restrictive about data ranges to reduce payloads to make them fit a technology stack - this will drive Distributor dissatisfaction with integration.

Controlling Volume

As a provider of service API’s, Suppliers need to expect that some of their consumers will inevitably drive bad calls - typically this would be because of a problem with the programming code, a bad loop causing the equivalent of a DoS attack on endpoints. Plans for handling this usually fall into two categories:

1. Rate Limiting - Many networking appliances and API Gateway offerings provide this - Suppliers should put these in place to protect themselves and help ensure uptime for all Distributors. Whatever rate limit is selected, it should be documented in the Suppliers integration guide. Ideally, this would also enable blocking inbound network traffic from a specific IP number as that’s the only “sure fire” way to handle excessive requests from a Distributor experiencing a problem.

2. Account Disabling - All PromoStandards API calls require a username and password - have a process in place to disable the account as needed. Remember that disabling an account doesn’t stop inbound network traffic - rate limiting and traffic blocking might ultimately be needed for that.

Setting Expectation with Consumers of your Data

As a provider of service API’s, setting expectations at the beginning of engagements will benefit the relationship and the perceived value of the integration.

1. Publishing Cadence - When publishing a service, the supplier should commit to a cadence for publishing data for that specific service (Inventory, Order Status, Product Data). The standard categories are as follows.

1. Problem Resolution - the supplier should provide contact information on where to submit issues, and commit to an SLA for responding to such issues. Where possible, the contact should not be an individual but an email box that is monitored regularly.

Audit Logs

From the outset, capturing queryable data around service traffic is essential.

1. You will want to be able to report on the success or your service. While number of transactions is only one part of the picture, being able to report on number of consumers and number of hits by service will be one part of your story of success.

2. You will be want to be able to troubleshoot reported issues and an audit log is essential for this.

3. You will want to be able to analyze patterns of use to plan for outages and to tweak your publishing cadence as necessary.