Integration Design Checklist

Revised: 12 November 2021

Introduction

This document will provide a standard checklist that should be reviewed with any customer or partner who is building integrations between Coupa and any other system in an effort to achieve the following goals:

  • Ensure integrations are designed to accommodate all possible data scenarios which may arise when integrating user-entered data between systems
  • Ensure integrations are designed in a loosely-coupled manner which prevents format changes in any system from breaking the integrations

CSV integrations

Step Details Requires Approval*
  Parsing by column name not position Yes
  Only Incremental / Delta data to be sent to Coupa/object and sending only the data that will be used in Coupa Yes
  Only Incremental / Delta data will be sent from Coupa and it will only be for the Final status (Ex: Invoice OKOTOPAY: Approved or Voided status) Yes
  No Scheduled Reports (Custom views on the object) should be used for automated integration as Coupa doesn’t support them as standard integration. Scheduled report if any should have condition to limit the data output (ex: daily run for last updated within 24hrs only) Yes
  Field names and formats are configurable rather than hard-coded No
  CSV files use the following conventions taken from RFC 4180.
  • The delimiter is a comma: ,
  • All fields are always text qualified (enclosed) with the double quote character: "
  • Double quote characters within a field are escaped by another double quote character. If a user enters: Status is "Green" in a comment field, this would be represented as "Status is ""Green"""
  • New Line characters may be allowed within qualified field values
  • Text-Encoding: UTF-8 (with No Byte Order Marker (BOM))
No
 

Accommodating all user-entered text scenarios

  • carriage returns and other special characters in text fields
  • unlimited text lengths in text block fields
  • truncating long text values to target system length
  • Multi-byte characters and length considerations (if required)
Yes
  Customer Must delete files from Outgoing directory in Coupa hosted sftp Yes
  Inbound regular delta feeds to Coupa should be combined in one file and every delta record update in source system should NOT be sent as one single file. Example: 
Scenario 1:
  • Supplier inbound to coupa runs once a day
  • 5 Suppliers updated in a day
  • One Supplier file should be sent to Coupa at end of the day and not 5 files
Scenario 2:
  • Supplier inbound to Coupa runs 3 times a day (10am / 4pm / 8pm)
  • 10 Suppliers updated in a day (3 before 10am, 4 between 10am – 4pm and 3 between 4pm – 8pm)
  • 3 Supplier files should be sent to Coupa and each file will have 3 or 4 or 3 records at 10am, 4pm, 8pm respectively
Yes
  For Incoming and Outgoing CSV Integrations data, only map the fields that are required by Coupa and required for Coupa business process. No
  Always validate the presence of elements in the XML/JSON before fetching the value as Coupa payload structure can change in the future to not display certain fields which have no or null values. Yes

* Customer / Partner Approval required on this prior to Development and should be part of MTP Ticket

API integrations

Step Details Requires Approval*
  Not exporting or importing data in bulk Yes
  Not using strict XSD validation Yes
  Only Incremental / Delta data to be sent to Coupa/object and sending only the data that would be used in Coupa  Yes
  All API calls MUST be part of the IRD and should be shared with and approved by Coupa Integration Architect  Yes
  Validate the presence of elements in the XML/JSON before fetching the value as Coupa payload structure can change in the future to not display certain fields which have no or null values. Yes
  Escaping/unescaping special xml characters No
  Paging in place for GET calls that may exceed 50 records No
  Error handling in place for PUT/POST calls No
  For Incoming and Outgoing API Integrations data, only map the fields that are required by Coupa and required for Coupa business process No
  Use API Filters/ Shallow/ Limited options for optimal API performance No