1

the assembly of my API Connect API contains two invokes. The first is calling an internal routing API to get some routing information. The response of this routing API should not be passed to the second invoke.

If I do not configure a 'response object variable' in the invoke of the routing API, the original request body is overwritten and the second API gets the result from the routing API as request body. And if I specify a 'response object variable' in the routing invoke, I can not access the content (json) of this variable in the following steps.

How can I solve this issue?

Thx 4 help.

tdeer
  • 135
  • 1
  • 6

2 Answers2

1

Rather than relying on reading the request object, you can read from your configured 'response object variable' later on in the flow. For instance, if your first invoke has a response object variable set to 'resp1', you can access the JSON payload using '$(resp1.body)' later on in the flow. Using this technique will allow you to store the response of each invoke in a separate object, avoiding the overwriting issue. These response object variables can be read just like any other context variable in the flow.

For more info, check out these links in the Knowledge Center:

Invoke Policy: https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/rapim_ref_ootb_policyinvoke.html

Context Variables: https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/capim_context_references.html

  • ok, thx. This works well for the body. But now I have the problem with the status.code. It seems that the status.code from the first invoke/response is send back to the API Caller. Should $(resp1.status.code) also work? Or how can I access the status.code of the invokes response? – tdeer Feb 07 '17 at 10:43
0

I don't understand this part:

[...] "And if I specify a 'response object variable' in the routing invoke, I can not access the content (json) of this variable in the following steps." [...]

Why can't you access the content of this variable in the following steps?


Save copy of the request...

... that you received. What I'd do is always save a copy of the data received in the invoke to a processed variable instead of the (raw) original request.

In your GatewayScript try something like this:

let objRequest = apim.getvariable("request");
let body = null;

Here I recommend you to change the body (if json) to a standard js object

if(objRequest && objRequest.hasOwnProperty("body")){
    try{
        body = JSON.parse(objRequest.body);
    }catch(e){
        body = objRequest.body;
    }
}

Remember to stringify the complete object before saving it as global variable. Is the only way to store it (because you can only store a string value in this kind of variables)

apim.setvariable("objRequest", JSON.stringify(objRequest));

Retrieve copy of the request...

...that you have saved in global variables you can get it from any other GatewayScript that you want this way:

let objRequest = JSON.parse(apim.getvariable("objRequest"));

Be careful not to assign an existent name to the apim.setvariable(name, value) because if you use "request" as name instead of "objRequest" (or other), you'll be replacing the original request element, and we don't want that to happen.


If you need to set or retrieve the status.code...

...you can do it with:

let statusCode = objRequest.body.status.code;
ferpel
  • 206
  • 3
  • 12