The Invoke policy has introduced the ability to reuse HTTP connections through the persistent connection property.
That was a comprehensive look at the Invoke policy and some of the crafty things you can do with it. We are sure that you can think of many more use cases. Some of those use cases might lead to you using other policies provided with APIC. One other important policy in the APIC arsenal is the switch policy. You will be introduced to this next.
Building a Switch policy
You will make changes to the inline-access API that you recently created. You will use a Switch policy and make a determination based upon a header variable (Environment) to process different branches of the message processing flow. Begin by opening the inline-access API in Designer. Navigate to the Gateway tab to review the single invoke policy:
- Click on the Invoke policy to bring up the property pane. Notice that the title is invoke. Replace the title invoke with the more readable title Production invoke. Making this change helps with the identification of the responsibility of the policy. You must follow the practice of giving meaningful names as per the identification of the responsibility of your policies and variables. You see that this new title is represented on the canvas as shown in Figure 4.33. Click Save to save the change.
Figure 4.33 – Adding readable code
2. Next, we want to add our switch logic policy. Drag the switch logic policy to the left of the Production invoke policy. You will drop it when a small square appears. Refer to Figure 4.34:
Figure 4.34 – Dragging switch before the Production script
You will now see a switch policy on the pane and the property screen on the right with Case 0 set to a condition of true.
3. Change the Case 0 condition using an Inline reference of $header(‘Environment’)=’Production’:
Figure 4.35 – Adding case to switch
4. Click on Add case to add our other leg to the switch. Using the same process as in step 3, change the value of Case 1 from true to message.headers.Environment = ‘Test’.
5. In Figure 4.36, you can see how the switch has changed to show the two possibilities:
Figure 4.36 – Adding a second case
You will notice that conditional logic for each case is built a bit differently using Inline references to the Environment request header. Notice the use of the $header(‘Environment’) and message.headers.Environment expressions. $header is just a functional extension of the variable message.headers.name in standard JSONata notation. You can use either of these techniques.
You will want to add a second Invoke policy to represent the Test environment.
6. Drag the Production invoke policy to Case 0 as shown in Figure 4.37. Drag and drop another Invoke policy for the Case 1 branch and change its title to Test invoke. Make sure that the URL for both Production invoke and Test invoke policies is set to $(api.properties.target-url)/$(request.parameters.patient-id). Click Save to save your API.
Figure 4.37 – Dragging Production invoke and Test invoke
You have configured your first switch policy. Your screen should look like Figure 4.38. This example assumes that the client application is passing a custom header, Environment, with the request.
Figure 4.38 – Use of Inline referencing in Switch conditions
Review the highlighted sections in Figure 4.38. You will notice that conditional logic for each case is built using inline references to the Environment request header.
It is time to test your API. You already know that the two Invoke policies point to the same service. So how will you know which branch your Switch policy took? You are going to learn how to use the Trace facility to answer this question.
7. Click on the Test tab and add the Environment header. Set the header to Test. Also set Patient-ID to d75f81b6-66bc-4fc8-b2b4-0d193a1a92e0. Click Send.
You should get the same results as before. But since the Invokes looked identical, how do you know whether it really executed Case 1? The next step shows you how.
8. After you run your test, click on the Trace tab. You will see the graphic that shows you which case statement was run. The other statement is grayed out. Figure 4.39 shows that result:
Figure 4.39 – Using Trace to determine the execution of Switch
You have now learned another valuable technique for accessing Parameters and API properties through the Inline Referencing method, as well as how to take advantage of the built-in testing and tracing capabilities of API Connect.
The last feature on the Invoke policy will be how to capture response objects and merge the information. Service chaining is common with APIs.