kate restful adapter for sap process integration: introduction
DESCRIPTION
Introduction and sample walktrough of the KaTe RESTful adapter for SAP Process IntegrationTRANSCRIPT
RESTful Adapter for SAP Process IntegrationIntroduction & Overview
RESTful Adapter - Basics
What can the RESTful adapter do for you?
RESTful Adapter - Basics
What can the RESTful adapter do for you?
Enable you to use SAP Process Integration to:
Publish „Pragmatic“* REST Services in XML & JSON
Invoke any„possible“ REST API or HTTP Resource
*) for a reference visit the excellent APIGee blog series on the topic
RESTful Adapter - Basics
It‘s more then an just another adapter!
RESTful Adapter - Basics
It‘s more then an just another adapter!
Convention over Configuration driven approach! (using metadata means less configuration)
API Console & WADL support to test & communicate with stakeholders
It‘s Developer & Operations „friendly“
RESTful Adapter - Basics
The 3 main building blocks of the adapter:
The adapter runtime PI sender/receiver channels
Design Conventions Model HTTP communication by convention Metadata enables API Console
Web UI (on top of adapter) Test HTTP Calls Display API Console & WADL*
*) available upwards PI >= 7.30
Web UI
Adapter
Design Conventions(WSDL/Msgs/JSON)
Enables
Describes
RESTful Adapter - Basics
What do we mean by Design Conventions?
RESTful Adapter - Basics
What do we mean by Design Conventions?
ESR Conventions to model http calls as PI messages
ESR Conventions to group resources as service interfaces
Conventions to use XML internal and „speak“ JSON externally
RESTful Adapter - Basics
What is the benefit of this Design Conventions?
ESR metadata drives the API Console / WADL Explain your REST API in a simple Web UI!
PI tools (mappings) can access any attribute of a http call No dynamic configurations or adaper modules needed!
Test drive any http call from the adapter Web UI Testdrive http calls before building a complete scenario
Convention over Configuration aproach!
RESTful Adapter - Basics
.. JSON is enabled by Conventions too!
RESTful Adapter - Basics
.. JSON is enabled by Conventions too!
Any published RESTful service is usable with XML & JSON
The adapter uses http content negotiation features to detect the expected content (Accept & Content-type headers)
No intensive configuration for JSON needed (modules etc...) Only choose: „XML compliant“ or „JSON compliant“ how XML turns into JSON
and back...
RESTful Adapter – Design Coventions
Action speaks louder then words
Let‘s see how it works by an example that comes with the adapter!
RESTful Adapter – Design Coventions
Action speaks louder then words
The adapter comes with a full CRUD example of a Partner resource stored in a database (along with more examples)
We will take a look at the example how a http POST call is modeled and published by the conventions!
RESTful Adapter – Design Coventions
Our example:
http POST call request with partner data that will return 201 Created status a location link to the new
partner resource
HTTP Client
POST http://myhost:50000/../PartnerAdapter
Location: http://myhost:50000/../Partner/1
RESTful Adapter – Design Coventions
Our example request as http call:
POST /ROAWeb/Resources/Partner?sample=123 HTTP/1.1
Host: myPIHost:50000Accept: application/xmlContent-Type: application/xml; charset=utf-8Authorization: Basic aHR0cHdhdGNoOmY= SampleHeader: testValue
<?xml version="1.0" encoding="UTF-8"?><Partner> <firstName>Anton</firstName> <lastName>Schmitt</lastName> <birthday>1977-01-12</birthday> <email>[email protected]</email></Partner>
POST data (body)
Http headers(we‘re interested in sample header)
URI Path, Method, Query Parameters
RESTful Adapter – Design Coventions
Our example request as PI request message
<urn:POST_Request xmlns:urn="urn:my:resource"> <identification> <resource name="Partner"/> <query><sample>123</sample> </query> </identification> <headers> <SampleHeader>testValue</SampleHeader> </headers> <body> <Partner> <firstName>Anton</firstName> <lastName>Schmitt</lastName> <birthday>1977-01-12</birthday> <email>[email protected]</email> </Partner> </body></urn:POST>
POST data (body)
Http headers(we‘re interested in sample header)
Parsed URI Path, Method, Query Parameters
RESTful Adapter – Design Coventions
And how would the response look like?
RESTful Adapter – Design Coventions
Our example response as PI response message:
<urn:POST_Response xmlns:urn="urn:my:resource"> <httpStatusCode>201</httpStatusCode> <headers> <location> http://myHost:50000/ROAWeb/Resources/Partner/1 </location> </headers></urn:POST>
Http headers(e.g.: here Location!)
HTTP Status: 201 Created
*) You might wonder about the origin of the Location header, this will be a few slides on ;)
RESTful Adapter – Design Coventions
Our example response as http call:
HTTP/1.1 201 Created
….Content-Type: application/xml; charset=utf-8Location: http://myhost:50000/ROAWeb/Resources/Partner/1
Http headers(e.g.: Location!)
HTTP Status: 201 Created
RESTful Adapter – Design Coventions
Now wasn‘t that simple?
RESTful Adapter – Design Coventions
Now wasn‘t that simple?
By that convention you set/access in a mapping: any path or resource id information (pre parsed) any query parameter any header parameter any http status code (or reason) any body (payload) – raw or as XML*
RESTful Adapter – Design Coventions
You might now just go and try the call with the API Console
As any call modeled by with this convention is exporable through the API Console
Just go here* on your PI Install:http://<yourPIHost>:50000/ROAWeb/Administration
*(/ROAWeb is the base path of the adaper)
RESTful Adapter – Design Coventions
The API Console enables you to:
Invoke RESTful Services (with XML & JSON)
Displays query/header parameters or the schema
Generates sample calls for PUT/POST requests
RESTful Adapter – Design Coventions
The API Console (for our POST Request)
Display Schema
Display result
Generate Sample Request
Send Payload
XML / JSON
RESTful Adapter – Design Coventions
Wait....but how did we create a current location header?
RESTful Adapter – Design Coventions
Wait....but how did we create a current location header?
The adapter comes with a mapping lib to construct relative & absolute links in the context of a call easily*
The functions take your resource ID and returns the current URI path + ID similar like Java REST frameworks (e.g. Jersey) (e.g. Supply „1“ turns into http://myhost:50000/.../Partner/1 )
*)Note! This feature is restricted to certain SP Levels (see SAP Note ) . However we have a workaround for older versions ;)))
RESTful Adapter – Design Coventions
And dynamic resource uri‘s by calling a RESTful servcie?
RESTful Adapter – Design Coventions
And dynamic resource uri‘s by calling a RESTful servcie?
As in previous example stated anything can be set Dynamic (in a Message Mapping) Static (in a Channel Configuration) Or both combined
URLs, URIs, Resource Ids, Host, Port, etc...
RESTful Adapter - Resources
How are different calls to a resource grouped in an PI interface?
RESTful Adapter - Resources
How are different calls to a resource grouped in an PI interface?
3 different ways to do it, group by: 1 Interface per resource (e.g. Simple CRUD) that responds to all HTTP Methods on
this resource („Method oriented“)
1 Interface hosts several resources and responds to all HTTP Methods below one base path („API oriented“)
Generic: Just receive anything below one base path („Generic“)
RESTful Adapter - Resources
How are different calls to a resource grouped in an PI interface?
E.g. Our example Partner resource with CRUD methods
Service Interface: PartnerOperations:POST (Request/Response)GET (Request/Response)PUT (Request/Response)DELETE (Request/Response/Fault*)
/<baseURI>/Partner
Bound bychannel
*) Faults are not mandatory but usable if needed to cover fault replies from receiver adapters
RESTful Adapter – Errors & HTTP Status
And how about PI faults & system errors?
RESTful Adapter – Erros & HTTP Status
And how about PI faults & system errors?
Few facts first: RESTful HTTP Status treatment and PI internal
Success/Errorhandling differs! PI: Response(happy Path), (defined) Faults & System Erros on
Transport RESTful: Plain HTTP Status Code
RESTful Adapter – Erros & HTTP Status
And how about PI faults & system errors?
The adapter closes this gap by: Enable you to return any http status in published Services from
regular response or fault messages (System Errors default to 500, but could be overriden)
Enable you to receive any http status for inspection / usage as regular response message from a receiver channel (or by your choice as fault or system error)
RESTful Adapter - JSON
And how about JSON ?
RESTful Adapter - JSON
And how about JSON ?
Any JSON input or output is available as XML internally in PI
The next few examples show the 2 different ways to do it to: Work XML „centric“ or Work JSON „centric“
RESTful Adapter - Basics
.. JSON „XML centric“ example!
JSON XML{ "tns:company": { "@xmlns:tns": “urn:my:comp", "name": "My Company", "address": { "city": "München", "zipCode": "83503", "houseNumber": "93a", "country": “DE" } }}
<?xml version="1.0" encoding="UTF-8"?><tns:company xmlns:tns=“urn:my:comp"> <name>My Company</name> <address> <city>München</city> <zipCode>83503</zipCode> <houseNumber>93a</houseNumber> <country>DE</country> </address></tns:company>
This is forth & backward compatible!
RESTful Adapter - Basics
.. JSON „JSON centric“ example!
JSON XML[ "1", "2„, 3 ]
<?xml version="1.0" encoding="UTF-8"?><a class="array"> <e type="string">1</e> <e type="string">2</e> <e type="number">3</e></a>
This is forth & backward compatible!
RESTful Adapter - Operations
And how about operations & monitoring?
RESTful Adapter - Operations
And how about operations & monitoring?
Channels can adjust log levels to show http information None, only headers or all (see below)
Payload
Headers
Method & URI
RESTAdapter - Security
What Security standards are supported?
Basic Authentication NTLM 1.x/2.x SSL Client Certificate oAuth1 / 2
RESTAdapter - Misc
What about other misc HTTP topics?
RESTAdapter - Misc
What about other misc HTTP topics?
E.g.: Posting and receiving Form Posts – fully supported
Fits often as more „natural“ choice
Post File Uploads – fully supported as multipart request Imagine posting a form with documents to start a Process?
RESTful Adapter - Samples
And what Samples do we provide „out of the box“?
RESTful Adapter - Samples
And what Samples do we provide „out of the box“?
Samples for publishing RESTful Example Services:
Publish REST Service in XML/JSON from relational Database (GET/PUT/POST/DELETE, JSON, Location Headers)
REST Form POST Request
RESTful Adapter - Samples
And what Samples do we provide „out of the box“?
Samples how to invoke RESTful Sample Services:
Call Twilio SMS API (JSON, Form Post, AuthToken)
Call LinkedIn API (oAuth1, JSON/XML)
Call Salesforce API (oAuth2, JSON/XML, PATCH Method)
RESTful Adapter
Interested in our SAP Certified offer?
We are pleased to hear your feedback
30 Day trial of the adapter available!
RESTful Adapter
Interested in our SAP Certified offer?
Contact us at :
WWW: http:www//kate-group.com/ T +49 711 90 79 64 65 F +49 711 90 79 64 66 E [email protected]