WM API Gateway - Request Transformation Payload - From JSON to XML?

, ,
1

Hi. I’m using webMethods API Gateway Version 10.7.0.4.207

I would like to know if I can use the Request Transformation part (in Policy), I can transform a JSON body sent from a host into an XML in order to be processed by the webMethods service in the Endpoint URL. Is this possible? If yes, what do I need to do in the Payload Transformation section, if that’s where to do it? How do I set up the JSON section there to facilitate?

For example: The host sent something like:

{"id":"001","name":"Andy"}

When it reaches the Endpoint URL, it would be read as:

<?xml version="1.0" encoding="UTF-8"?>
<root>
   <id>001</id>
   <name>Andy</name>
</root>

Thank you

2

@kristian.wijaya1234 , Yes , you can do the payload transformation by using XLT Transformation or by calling webMethods IS service and form the native format request. Refer the link under payload transformation section.

https://documentation.softwareag.com/webmethods/api_gateway/yai10-5/10-5_API_Gateway_webhelp/index.html#page/api-gateway-integrated-webhelp/gtw_transformation_request.html

4

@DINESH_J Thank you for the answer, it’s close but there’s some more I’d like to ask since I’m new here:

It says that “When the incoming request is in JSON, you can use a XSLT file similar to the below sample:”

So does this mean it converts JSON into XSLT, or it converts into XML using that XSLT file? Because my goal is “JSON becomes XML”, not “JSON becomes XSLT”. (Of course I understand that calling webMethods IS Service is an option too, but I want to know more about the Payload Transformation process first)

5

@kristian.wijaya1234 , Its uses the XSLT ( Metadata ) to convert target structure . i.e JSON to XML using XSL Transformation file.

6

The challenge with generic XML/JSON translation is there are corner cases where additional “hints” are needed. For example, consider the following:

{
    "foos" : [
        {
            "prop1":"value1",
            "prop2":"value2"
        },
        {
            "prop1":"value3", 
            "prop2":"value4"
        }
    ]
}

Convert that to XML you get:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
  <foos>
    <prop1>value1</prop1>
    <prop2>value2</prop2>
  </foos>
  <foos>
    <prop1>value3</prop1>
    <prop2>value4</prop2>
  </foos>
</root>

No problem so far. And the reverse is not a problem either – as long as there are miultiple present. If there is only one, then the generic translation from XML to JSON would end up like this – no array:

{
    "foos" :
        {
            "prop1":"value1",
            "prop2":"value2"
        }
}

When the Gateway hosts a SOAP interface, there is an option to expose that as a so-called “REST transformation.” It works okay, just be aware of the limitation. And unfortunately, I don’t think there is an option for the reverse – a REST API with a “SOAP transformation” option isn’t there.

What we do in this case is route things through Integration Server. Similar to what @DINESH_J suggests using request/response transformation policies, but instead use an IS service as the native endpoint instead of the “real” endpoint. Have it do the translation using document types, which provides the necessary “hints” when needed. Then have IS interact with the endpoint that would have been configured as the native endpoint in the API policy.

HTH

1 Like
7

@reamon Just to be sure, to which part is this ‘IS Service in a native endpoint’ referring to:

  1. Put the IS Service URL into the Endpoint URL located at the ‘Routing’ part
  2. Put the IS Service URL into the ‘Invoke webMethods IS’ part (in the webMethods IS Service part)

And if it’s okay with you, can you also show me an example based on the link @DINESH_J gave about what to enter in the part for “”? For this example, let’s use the first JSON you gave and attempting to change it to XML.

And finally, one last thing, especially for @DINESH_J : Payload Transformation has a form for ‘Payload type’ where we can choose between JSON, XML, Text, and then there’s a text field where we can type content in it. What do I fill it with? Perhaps an example will help?

Thank you. I’m sorry I ask a lot, but this is because I’m pretty new at this.

8

Those are indeed the 2 options. Option 1 you list is what we’ve done in this case – set Routing to send the data to an Integration Server endpoint.Note that for us in this case, the IS instance is a separate server, not the IS instance that is hosting the API GW. Option 2 is what you asked about and what @DINESH_J provide info about.

Another possible approach – you stated in your original post: “…to be processed by the webMethods service in the Endpoint URL”

I assume the “webMethods service” is an item in Integration Server that accepts XML. What you could do is define another service in Integration Server that accepts the JSON, parses it as needed to the same IS document that the original service supports then call that. In other words, you’d have service A that accepts the XML, converts that to an IS document and calls service C. Service B would accept JSON, coverts that to that same IS document and calls service C. The built-in capabiliites support doing this concept in a couple of ways. I would suggest chasing that avenue rather than have API GW do this. Use API GW as the “gatekeeper” not a transformer.

As always, just an option to consider.

9

@reamon All right. So as long as the Service is within Integration Server and testable, we can run it via ‘Invoke webMethods IS’, right?

I’m thinking of using Flow Service, but I’d like to know if there are other kinds of service better for this job. If it’s flow service, then I’m thinking the process will be like changing JSON String into Document before changing that Document into XML String. I’m a newbie so this is kinda new to me. Let me know if this is getting it right too… Thanks!

10

@Kristian - YES your statement above is valid and going in right direction wrt transformation part

Utilizing. Json string to Document (Json services)–>Document to xmlString via pub.xml services

HTH,
RMG

11

For the “Request Processing” and the “Response Processing” policies, yes, “Invoke webMethods IS” is the setting. For this option, the service would be on the “local” IS that hosts Gateway.

For the “Routing” policy using the “Endpoint URL” it can be any service anywhere, including a service hosted on any Integration Server not just the one hosting Gateway. Given that FLOW is the primary language of Integration Server, and Java is to avoided if possible/reasonable, then using FLOW is the preferred approach, IMO.

For both approaches, your description of convert from JSON to document to XML and the reverse is indeed the way to go. You can define a document type that helps inform the XML string to document conversion so that arrays/lists are handled correclty in presnce of a singleton value.

HTH.

1 Like
12

That is a great callout.
Since JSON require arrays to be called out specifically - it requires knowledge of how JSON structure needs to be to perform transformation.
Using XSLT or using IS Documents with array structure would be a way to achieve such transformation.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.