Presentation from the developer track at I Love APIs London 2016 featuring Andrew Liles, DigitasLBi, George Taylor, DigitasLBi and Timothy Yip, DigitasLBi. Managing 100s of Partner API integrations are difficult, because it requires careful management of both business relationships and technology, but what happens if you need to scale 1000s of integrations all across the globe? DigitasLBi present the technology and governance techniques used to manage the thousands of apps and the thousands of backend systems. This presentation covers: 1. How to handle 1000s of integration configurations 2. How to govern the continual evolution of 10 APIs, publicising contracts such that automated tools can enforce the contracts 3. Emulating integrations during development

1. How to scale 1000s of API
integrations and not lose your mind
Andrew Liles
Global Technical Partner, DigitasLBi
1
George Taylor
Technical Architect, DigitasLBi

2. The views expressed in this presentation are those of
the presenter, and not necessarily those of Apigee
Corporation or the presenter’s employer.
2

3. Agenda
3
Context
1.
How to handle 1000s of integration configurations
2.
How to govern the continual evolution of 10 APIs,
publicising contracts such that automated tools
can enforce the contracts
3.
Emulating integrations during development
©2016 Apigee. All Rights Reserved.

4. 4
Consumer Vehicle websites

5. Websites&apps
Integrations
Lots of websites
5
©2016 Apigee. All Rights Reserved.
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Development
QA
UAT
Staging
Production
Hot Fix
2000 sites
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
3300 "
integrations

6. Websites
Integrations
Lots of websites
6
©2016 Apigee. All Rights Reserved.
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Development
QA
UAT
Staging
Production
Hot Fix
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
3300 "
integrations
2000 sites
Using Apigee
Treated as
Apigee
apps

7. Websites
Integrations
But its really a CMS, commerce websites & apps
7
©2016 Apigee. All Rights Reserved.
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Development
QA
UAT
Staging
Production
Hot Fix
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Brand 1 / UK
Integration
implementation
Brand 1 / US
Integration
implementation
Brand 2 / CN
Integration
implementation
Switch based on "
brand/market key

8. • In Apigee we
chose this
organisation, but
still the base app
requires up to a
100 settings.
• We needed a more
sophisticated way
to maintain these
Custom Attributes
Implementation in Apigee
8
©2016 Apigee. All Rights Reserved.
Dev
Testing
Production
Organisation
Brand 2
UK
FR
DE
BR
TH
UAT
Hot Fix
Staging
Environment
Developers
Developer
Apps
Brand 3
Brand 1
Apigee
terminology

9. • We’ve implemented the same hierarchy
in properties files (under Git)
• We derive the App’s Custom Attributes
through:
– Inheritance from the parent level "
è gives us defaults
– Use of Templates "
è allows us to enforce integrity:
• Must have attributes
• Option attributes
• Deny any other attributes
– Assurance using Unit Tests
Implementation in Apigee
9
©2016 Apigee. All Rights Reserved.
Dev
Testing
Production
Organisation
Brand 2
UK
FR
DE
BR
TH
UAT
Hot Fix
Staging
Environment
Developers
Developer
Apps
Brand 3
Brand 1
Apigee
terminology

10. Agenda
10
©2016 Apigee. All Rights Reserved.
Context
1.
How to handle 1000s of integration configurations
2.
How to govern the continual evolution of 10 APIs,
publicising contracts such that automated tools
can enforce the contracts
3.
Emulating integrations during development

11. • 10 APIs
– 3 major versions of some
– more new ones to come
• 57 REST resources, always JSON
• Any major change implies work for
consumers & producers
Consumer stakeholders:
• Developers of core websites
• Developers of affiliated websites
• Developers of mobile apps
Producer stakeholders
• Brand/Country IT teams to which the APIs
connect
API Governance
11
APIs
Stakeholders
©2016 Apigee. All Rights Reserved.

12. API Governance
12
©2016 Apigee. All Rights Reserved.
New/changed "
Feature
API "
Change Request
Review by API "
Governance Board
Publish"
Contract
MuleSoft’s
API Designer

13. API Governance
13
©2016 Apigee. All Rights Reserved.
New/changed "
Feature
API "
Change Request
Review by API "
Governance Board
Publish"
Contract
• RAML
• JSON with"
JSON Schema

14. API Governance
14
©2016 Apigee. All Rights Reserved.
New/changed "
Feature
API "
Change Request
Review
Publish
• RAML
• JSON with"
JSON Schema
• All reviewed in Git"
(Atlassian Stash)

15. API Governance
15
©2016 Apigee. All Rights Reserved.
New/changed "
Feature
API "
Change Request
Review
Publish
• RAML
• JSON with"
JSON Schema
• All reviewed in Git"
(Atlassian Stash)
• Unit Test ensures"
RAML and JSON "
example matches"
schema

16. API Governance
16
©2016 Apigee. All Rights Reserved.
• When the API
implementation is built,
automated tests (using
Cucumber) not only
assert the values, but
ensure that the
responses adhere to
the contract
Integrations
API contract

17. Agenda
17
©2016 Apigee. All Rights Reserved.
Context
1.
How to handle 1000s of integration configurations
2.
How to govern the continual evolution of 10 APIs,
publicising contracts such that automated tools
can enforce the contracts
3.
Emulating integrations during development

18. Websites
Integrations
Emulating integrations
18
©2016 Apigee. All Rights Reserved.
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Development
QA
UAT
Staging
Production
Hot Fix
Brand 1
Brand 2
Brand 3
Brand 4
Brand 5
UK
FR
DE
BR
TH
AU
NZ
US
IE
CA
RU
ZA
CN
NL
JP
PL
ES
etc
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Brand 1 / UK
Integration
implementation
Brand 1 / US
Integration
implementation
Brand 2 / CN
Integration
implementation
Mock Service

19. Emulating integrations
19
©2016 Apigee. All Rights Reserved.
Component
Component
Component
Component
Component
Component
Mock Service
• Design goal: no programming required to use, just construct
JSON and name the file appropriately
• For GET requests Mock Service converts a Resource into file
path and returns that for the request. If not found, a 404
• POST writes a file to the file server, so a test engineer can
validate the POST
• PUT, PATCH, DELETE & HEAD all supported
• Custom handlers used for special cases, e.g. login

20. Emulating integrations
20
©2016 Apigee. All Rights Reserved.
Component
Component
Component
Component
Component
Component
Mock Service

21. Thank you
Andrew Liles
Global Technical Partner, DigitasLBi
George Taylor
Technical Architect, DigitasLBi