Introduction
SAP Cloud Integration version 3.30.**/ 4.17.** comes with an enhancements/feature for message mapping where in you can upload and map the Swagger/Open API Spec JSON file. This blog describes about this new enhancement.
Swagger/Open API Spec JSON
When we say Swagger/Open API Spec JSON, we are supporting the JSON files based on OpenAPI Spec 2.0 and 3.0 version and especially the JSON definition files of the REST APIs hosted on https://api.sap.com . For a given REST API, you can download the definition file of the same as shown in the screenshot below. Here a JSON specification file of an Ariba REST API is used.
Ariba Asset Management API on SAP API Hub
Click on Download API Specification -> JSON
JSON File Downloaded
Once you download the Swagger JSON, you can use it in your message mapping. To use this feature, you need Message Mapping flow step version 1.1. When you drag and drop the message mapping flow step of the said SAP Cloud Integration version, it will be of the latest one, i.e. version 1.1.
Below are the screenshot on how to see a flow step version.
Click on (i) icon
Version number of the flow step
You can upload this JSON file similar to other currently supported XSD, WSDL or EDMX file. Just click on source OR target part of the message mapping an upload it. Below sequence of screenshots shows the different UI screens you see once you select and upload the swagger JSON file.
Search and add Message Mapping Flow step after click (+) on Content Modifier
Click on Create icon/speed button
Provide a name for the message mapping
Mapping Editor Opens up -> Add source message
Upload the downloaded JSON file
Select API Path
Source structure in Mapping
Upload the target structure and define mapping
All the standard functions, along with Groovy script based custom functions/user defined functions (UDFs) of the mapping expression editor are supported for the uploaded swagger JSON. You can use these functions for your mapping definition needs.
You can upload other supported file as well in combination with JSON. That is, JSON file at the source side and a WSDL file at the target side (or vice versa) of the message mapping as per your integration scenario needs.
Further, you can complete the message mapping and/or integration flow development as usual and deploy, run the integration scenario.
Planned Enhancements
Below topics are planned for the future enhancements.
JSON Schema as per https://json-schema.org/
As of now, only swagger JSON files are supported, and going forward we will be working on the provide the support for JSON files which adhere to the specifications as defined in https://json-schema.org/. This shall come handy when you have a JSON structure for other kind/third party systems of integrations which understands JSON data files/payloads adhering to said spec.
Multi Mapping
Currently, the Swagger JSON is not supported in multi mapping. In feature increments we will be working on to enable it.
Summary
Support of swagger JSON will now enable you to develop the integration scenarios, which probably pure JSON based scenarios communicating with REST APIs without the need of JSON <-> XML converter steps which were previously mandatorily required because message mappings were able to only understand XML payloads. Now can you avoid JSON <-> XML converter steps for such scenarios.
Hi Deepak,
Great to see native support of JSON in Message mapping.
Is there also a plan to provide message validation based on OAS? I think that will be very helpful too.
Thanks,
Santhosh.
Hi Santhosh,
Thanks for the input.
Can you elaborate about your expectation with “provide message validation”, and OAS I assume that you are using short form of OpenAPI Specification.
This will help me answering your query.
Thanks
Deepak
Hi Deepak,
Yes. I was referring to Open API Specification and validating the inbound JSON message payload schematically to it.
Thanks,
Santhosh.
Hi Deepak,
these are great news! Really looking forward to get the new functions pushed to our tenant.
One question: How do the mappings work “under the hood”. Have you implemented a native JSON mapping engine or will JSON payloads internally, automatically converted to XML and then handled by the current/classic CPI/PI mapping engine?
Background: I’m asking this because I fear unexpected outcomes, in case there would be a silent JSON-to-XML conversion instead of a JSON native engine.
Hi Raffael,
Thanks for the feedback.
When the JSON file is uploaded, it is used and represented in SAP’s message mapping (MMAP) format (equivalent to your statement of >> current/classic CPI/PI mapping engine<<).
We aren’t doing any conversion to XML again.
Due to direct interpretation in MMAP, we were able to provide standard + groovy script based custom functions support, display queue and mapping simulation support in the first release iteration of JSON support in message mapping.
Thanks
Deepak
Thank you for sharing this, I am sure it will be a useful feature. We’re still on 3.29. Is there a way to see all new features in the upcoming release?
Thank you.
Hi Alexey,
There will be a blog written on 2020 release cycles. Once available, I will share with you.
For 3.30.**, the planned customer release is on or after 24th Oct 2020. I will update you in case of any deviations.
Thanks
Deepak
Thank you very much for the update, Deepak.
Nice one.Thanks for sharing!
Hi Deepak,
This is great.
Is the any roadmap to support RAML in future?
Thanks,
Apu
Hi Apu,
my 2 cents here: as far as I can see from my customers, RAML has seen very poor adoption. I just checked against Google Trends too:
https://trends.google.de/trends/explore?date=all&q=raml,openapi,swagger
So my guess (I am not involved in product management) is that we will not have native support for RAML. But you can still use open source or web tools to transform your RAML into OpenAPI. We also feature that in SAP API Management, in the API Designer (API Portal/Develop/API Designer/Paste/Raml).
BR!
Sven