As Siddharth explained, Apigee Edge is not an ESB; it does not provide broad support for integration and elaboration. But if your needs are as simple as you describe, Apigee Edge will work just fine for your purposes.
There are various ways to do it. One way to accomplish what you want is to:
- Build an API Proxy
- set API-1 as the target
- In the "response flow", set an XSL policy that loops through the procedureId values, and gets an XML document from API-2 for each one. Then this XSL concatenates a transformation of each one of those retrieved document, into one consolidated XML response.
The XSL "apply-templates" element effectively acts as the loop that you mentioned. It can loop through each procedureId returned from the original endpoint.
Many people are unaware that an XSL stylesheet, including one running within Apigee Edge, can retrieve an XML document from an external endpoint. (see also, this related post.) . This is done with a statement like this:
<xsl:variable name="xdoc" select="document($location)"/>
...where location refers to an XSL variable pointing to an https endpoint. The full sheet might look like this:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- this is a parameter set in the XSL Policy config -->
<xsl:param name="base_location" select="''"/>
<xsl:template match="/">
<!-- Elaborate the procedures -->
<root>
<xsl:apply-templates select="root/procedures/procedureId" />
</root>
</xsl:template>
<xsl:template match='procedureId'>
<xsl:variable name="location" select="concat($base_location, normalize-space(./text()))"/>
<!-- the following retrieves the remote document into a variable
available to the stylesheet -->
<xsl:variable name="xdoc" select="document($location)"/>
<xsl:apply-templates select="$xdoc/root/procedureDetails"/>
</xsl:template>
<xsl:template match='procedureDetails'>...</xsl:template>
</xsl:stylesheet>If API-1 returns something like this:
<root>
<procedures>
<procedureId>5800</procedureId>
<procedureId>2842</procedureId>
</procedures>
</root>
...and if API-2 returns something like this:
<root>
<procedureDetails>
<procedureId>5800</procedureId>
<Detail>
<DetailType>Last change</DetailType>
<value>2018-12-10T19:11Z</value>
</Detail>
<Detail>
<DetailType>Service status</DetailType>
<value>true</value>
</Detail>
</procedureDetails>
</root>
..then that stylesheet will produce something like this:
<root>
<procedure>
<id>5800</id>
<Last_change>2018-12-09T19:11Z</Last_change>
<Service_status>true</Service_status>
</procedure>
<procedure>
<id>2842</id>
<Last_change>2018-12-08T17:18Z</Last_change>
<Service_status>true</Service_status>
</procedure>
</root>
To get this to work, you would need to specify a parameter to the XSL policy, like this:
<XSL name='XSL-ElaborateAndMashup'>
<Source>response</Source>
<OutputVariable>response.content</OutputVariable>
<ResourceURL>xsl://elaborate-and-mashup.xsl</ResourceURL>
<Parameters ignoreUnresolvedVariables='true'>
<Parameter name='base_location' ref='base_location'/>
</Parameters>
</XSL>
...and the context variable 'base_location', would need to hold something like "https://base.com/foo/" .
Attached is a working API Proxy that shows all the various policies. apiproxy-elaboration-mashup.zip
Another way is to use JavaScript to do the retrieving. In that case you will probably want to mashup the retrieved contents in the JS callout. You can do that with e4X.
A third way is to retrieve all the docs with JS, then mash them up in XSL. I think I like that way the best. Because you can retrieve documents in JS asynchronously, this approach might perform better at scale than the simpler approach of using the XSL to retrieve documents serially.
You could also use a Hosted Target implementation to parse the initial XML and then invoke N other endpoints. But that seems like overkill for a simple http callout.
LinkedIn
Twitter
