I cannot really comment on the use of the Event Companion.
An alternative approach is to loop over the result of the first API call, take each 'product' and make the second REST call as part of a looping process.
Here's an example flow with a brief description:
- The 1st REST call in the test retrieves the product list. The response (product list elements) are filtered to determine how many times the loop needs to occur.
- Steps 2 & 3 are hacks to compensate for not knowing what your API call response looks like.
Step 2 parses a simple JSON payload since I have nothing I can call in Step 1
Step 3 converts the JSON to XML and creates the filter of the # of occurs using an XPath count().
- The Loop Over List of Products iterates the structure one element at a time. Filters on this step extract product type and product SKU.
- Generate Endpoint URI assumes that a URI is all that is needed so it constructs one.
I used a switch(); however, the implementation could be done in a number of ways depending on the API call to retrieve the product.
Assertions might be used in situations where a particular product might have a unique API call / endpoint. In this case, you might implement multiple different REST call steps that branch back to the loop dataset when finished.
- HTTP Get is a REST call that uses the constructed URI
- Add other logic is just that... Add other logic as necessary.
The attached test demonstrates the above flow. For obvious reasons, your version will require modifications.