KaTe RESTful adapter for SAP Process Integration: Introduction

3,972 views

Published on

Introduction and sample walktrough of the KaTe RESTful adapter for SAP Process Integration

Published in: Technology, News & Politics
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,972
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The adapter comes with a mapping lib function.
    This function simplifies the construction of links of resources
    The function takes ID argument and produces a relative OR absolute Link (similar like frameworks like Jersey)*
  • RESTful HTTP Status treatment & internal PI Messaging Success/Errorhandlng differs!
    PI: Response (Happy Path!), Faults & System Errors
    RESTful: HTTP Status Code
    The adapter closes this gap by enabling
    Invoked calls in receiver channels as regular response, fault or system error by error code.
    Return any http status codes in published RESTful services by regular response mappings or faults
  • RESTful HTTP Status treatment & internal PI Messaging Success/Errorhandlng differs!
    PI: Response (Happy Path!), Faults & System Errors
    RESTful: HTTP Status Code
    The adapter closes this gap by enabling
    Invoked calls in receiver channels as regular response, fault or system error by error code.
    Return any http status codes in published RESTful services by regular response mappings or faults
  • KaTe RESTful adapter for SAP Process Integration: Introduction

    1. 1. RESTful Adapter for SAP Process Integration Introduction & Overview
    2. 2. RESTful Adapter - Basics What can the RESTful adapter do for you?
    3. 3. 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
    4. 4. RESTful Adapter - Basics It‘s more then an just another adapter!
    5. 5. 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“
    6. 6. RESTful Adapter - Basics The 3 main building blocks of the adapter:  The adapter runtime Adapter  PI sender/receiver channels Describes  Design Conventions  Model HTTP communication by convention  Metadata enables API Console  Web UI (on top of adapter)  Test HTTP Calls  Display API Console & WADL* Design Conventions (WSDL/Msgs/JSON) Enables Web UI *) available upwards PI >= 7.30
    7. 7. RESTful Adapter - Basics What do we mean by Design Conventions?
    8. 8. 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
    9. 9. 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!
    10. 10. RESTful Adapter - Basics .. JSON is enabled by Conventions too!
    11. 11. 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...
    12. 12. RESTful Adapter – Design Coventions Action speaks louder then words Let‘s see how it works by an example that comes with the adapter!
    13. 13. 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!
    14. 14. 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 Adapter POST http://myhost:50000/../Partner HTTP Client Location: http://myhost:50000/../Partner/1
    15. 15. RESTful Adapter – Design Coventions Our example request as http call: POST /ROAWeb/Resources/Partner?sample=123 HTTP/1.1 Host: myPIHost:50000 Accept: application/xml Content-Type: application/xml; charset=utf-8 Authorization: Basic aHR0cHdhdGNoOmY= SampleHeader: testValue <?xml version="1.0" encoding="UTF-8"?> <Partner> <firstName>Anton</firstName> <lastName>Schmitt</lastName> <birthday>1977-01-12</birthday> <email>a.schmit@kate-group.com</email> </Partner> URI Path, Method, Query Parameters Http headers (we‘re interested in sample header) POST data (body)
    16. 16. 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>a.schmit@kate-group.com</email> </Partner> </body> </urn:POST> Parsed URI Path, Method, Query Parameters Http headers (we‘re interested in sample header) POST data (body)
    17. 17. RESTful Adapter – Design Coventions And how would the response look like?
    18. 18. 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 Status: 201 Created Http headers (e.g.: here Location!) *) You might wonder about the origin of the Location header, this will be a few slides on ;)
    19. 19. RESTful Adapter – Design Coventions Our example response as http call: HTTP/1.1 201 Created HTTP Status: 201 Created …. Content-Type: application/xml; charset=utf-8 Location: http://myhost:50000/ROAWeb/Resources/Partner/1 Http headers (e.g.: Location!)
    20. 20. RESTful Adapter – Design Coventions Now wasn‘t that simple? 
    21. 21. 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*
    22. 22. 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)
    23. 23. 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
    24. 24. RESTful Adapter – Design Coventions The API Console (for our POST Request) Send Payload Generate Sample Request Display Schema XML / JSON Display result
    25. 25. RESTful Adapter – Design Coventions Wait....but how did we create a current location header?
    26. 26. 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 ;)))
    27. 27. RESTful Adapter – Design Coventions And dynamic resource uri‘s by calling a RESTful servcie?
    28. 28. 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...
    29. 29. RESTful Adapter - Resources How are different calls to a resource grouped in an PI interface?
    30. 30. 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“)
    31. 31. RESTful Adapter - Resources How are different calls to a resource grouped in an PI interface? E.g. Our example Partner resource with CRUD methods /<baseURI>/Partner Bound by channel Service Interface: Partner Operations: POST (Request/Response) GET (Request/Response) PUT (Request/Response) DELETE (Request/Response/Fault*) *) Faults are not mandatory but usable if needed to cover fault replies from receiver adapters
    32. 32. RESTful Adapter – Errors & HTTP Status And how about PI faults & system errors?
    33. 33. 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
    34. 34. 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)
    35. 35. RESTful Adapter - JSON And how about JSON ?
    36. 36. 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“
    37. 37. RESTful Adapter - Basics .. JSON „XML centric“ example! { JSON "tns:company": { "@xmlns:tns": “urn:my:comp", "name": "My Company", "address": { "city": "München", "zipCode": "83503", "houseNumber": "93a", "country": “DE" } } } XML <?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!
    38. 38. RESTful Adapter - Basics .. JSON „JSON centric“ example! JSON [ "1", "2„, 3 ] XML <?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!
    39. 39. RESTful Adapter - Operations And how about operations & monitoring?
    40. 40. RESTful Adapter - Operations And how about operations & monitoring?  Channels can adjust log levels to show http information  None, only headers or all (see below) Method & URI Headers Payload
    41. 41. RESTAdapter - Security What Security standards are supported?     Basic Authentication NTLM 1.x/2.x SSL Client Certificate oAuth1 / 2
    42. 42. RESTAdapter - Misc What about other misc HTTP topics?
    43. 43. 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?
    44. 44. RESTful Adapter - Samples And what Samples do we provide „out of the box“?
    45. 45. 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
    46. 46. 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)
    47. 47. RESTful Adapter Interested in our SAP Certified offer? We are pleased to hear your feedback 30 Day trial of the adapter available!
    48. 48. 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 info@kate-group.com

    ×