In this lab, you learn about handling faults in an Apigee proxy.
In this lab, you learn how to perform the following tasks:
For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.
Sign in to Qwiklabs using an incognito window.
Note the lab's access time (for example, 1:15:00), and make sure you can finish within that time.
There is no pause feature. You can restart if needed, but you have to start at the beginning.
When ready, click Start lab.
Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.
Click Open Google Console.
Click Use another account and copy/paste credentials for this lab into the prompts.
If you use other credentials, you'll receive errors or incur charges.
Accept the terms and skip the recovery resource page.
Google Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud.
Google Cloud Shell provides command-line access to your Google Cloud resources.
In Cloud console, on the top right toolbar, click the Open Cloud Shell button.
Click Continue.
It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. For example:
gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.
Output:
Example output:
Output:
Example output:
These assets have already been added to the Apigee organization:
These assets will be added to the Apigee organization as soon as the runtime is available:
The highlighted items are used during this lab.
In this task, you add a FaultRule to handle a JSONThreatProtection policy fault and rewrite the error message.
In the Google Cloud console, on the Navigation menu (
The Apigee console page will open.
If Apigee is not pinned, search for Apigee in the top search bar and navigate to the Apigee service.
Hover over the name, then click the pin icon (
The Apigee console page will now be pinned to the Navigation menu.
On the left navigation menu, select Proxy development > API proxies.
Select the retail-v1 proxy.
Click the Develop tab.
You are modifying the version of the retail-v1 proxy that was created during Labs 1 through 9.
In the Navigator pane, click Proxy endpoints > default.
Click on the default proxy endpoint in the Navigator.
In the default.xml pane, you see the XML representation of the default proxy endpoint. In the file you might see an empty FaultRules element: <FaultRules/>.
If you have an empty FaultRules element (<FaultRules/>) in default.xml, delete that line.
Create a new FaultRules element at the same location, inside the ProxyEndpoint element:
This is a fault rule that is executed when the JSONThreatProtection policy raises a fault. The policy name in the condition (JSONTP-Protect) must exactly match the name of the JSONThreatProtection policy in your proxy. Fault variables that are generated by the JSONThreatProtection policy are listed in the documentation for the policy.
The FaultRules flows do not show up in the graphical representation of the proxy endpoint, so you will need to create a policy without attaching it to a flow, and then add it to the XML.
In the Navigator pane, for Policies, click Add Policy (+).
In the Create policy pane, for Select policy, select Mediation > Assign Message.
Specify the following values:
| Property | Value |
|---|---|
| Name | AM-400JSONThreat |
| Display name | AM-400JSONThreat |
Click Create.
Click on Policies > AM-400JSONThreat.
Replace the AssignMessage configuration with:
This policy rewrites the error response that was generated by the JSONThreatProtection policy. The status code is set to 400 Bad Request, which is more appropriate than the default status code provided by the policy (500 Internal Server Error).
The replaceFirst template inside the payload is used to strip off the beginning of the error message. error.message for this policy looks like this:
The square brackets ([ ]) and colons (:) in the regular expression must be escaped by using a backslash because they are reserved characters in regular expressions.
In the Navigator pane, click Proxy endpoints > default.
Insert the following step inside the FaultRule element:
The final FaultRules section in the ProxyEndpoint looks like this:
Click Save, and then click Save as New Revision.
In this task you raise a fault if the request is not correct.
You may have noticed that if you do not pass a Content-Type header set to application/json, the JSONThreatProtection policy will not validate the request.
To prevent this scenario, you should raise a fault if the Content-Type header is required but not correctly specified.
In the Navigator pane, click Proxy endpoints > default > createOrder.
In the createOrder request flow, click Add Policy Step (+).
In the Add policy step pane, select Create new policy, and then select Mediation > Raise Fault.
Specify the following values:
| Property | Value |
|---|---|
| Name | RF-InvalidContentType |
| Display name | RF-InvalidContentType |
| Condition | request.header.Content-Type != "application/json" |
Click Add.
In the Navigator pane, click Policies > RF-InvalidContentType.
Change the RF-InvalidContentType policy configuration to:
In the Navigator pane, click Proxy endpoints > default > createOrder.
In the Request createOrder flow*, select the the RaiseFault policy and drag it so it precedes the JSONThreatProtection policy:
The createOrder flow XML should now look like this:
Click Save.
In this task, you block all requests that don't match a conditional flow in the proxy endpoint request.
In the Navigator pane, click Proxy endpoints > default.
In the graphical representation of the default proxy endpoint, click Add Conditional Flow (+):
Set the following properties. Because the wizard does not allow you to create a flow without a condition, you will remove the condition manually:
| Property | Value |
|---|---|
| Flow Name | 404NotFound |
| Description | Return 404 Not Found |
| Condition Type | select Custom |
| Condition | DELETE THIS |
Click Add.
Remove the "DELETE THIS" condition from the 404NotFound flow. This flow should always be the last flow in the list of conditional flows. With no condition, the 404NotFound flow will always be executed if none of the previous flows are executed.
After you remove the "DELETE THIS" condition, your 404NotFound flow should look like this:
In the Navigator pane, click Proxy endpoints > default > 404NotFound.
In the 404NotFound request flow, click Add Policy Step (+).
In the Add policy step pane, select Create new policy, and then select Mediation > Raise Fault.
Specify the following values:
| Property | Value |
|---|---|
| Name | RF-404NotFound |
| Display name | RF-404NotFound |
Click Add.
In the Navigator pane, click Policies > RF-404NotFound.
Change the RF-404NotFound policy configuration to:
Click Save, and then click Deploy.
To specify that you want the new revision deployed to the eval environment, select eval as the Environment, and then click Deploy.
Click Confirm.
A proxy that is deployed and ready to take traffic will show a green status on the Overview tab.
When a proxy is marked as deployed but the runtime is not yet available and the environment is not yet attached, you may see a red warning sign. Hold the pointer over the Status icon to see the current status.
If the proxy is deployed and shows as green, your proxy is ready for API traffic. If your proxy is not deployed because there are no runtime pods, you can check the provisioning status.
In Cloud Shell, to confirm that the runtime instance has been installed and the eval environment has been attached, run the following commands:
When the script returns ORG IS READY TO USE, you can proceed to the next steps.
While you wait, learn more by reviewing:
In this task, you validate the three changes you made to the proxy.
The eval environment in the Apigee organization can be called using the hostname eval.example.com. The DNS entry for this hostname has been created within your project, and it resolves to the IP address of the Apigee runtime instance. This DNS entry has been created in a private zone, which means it is only visible on the internal network.
Cloud Shell does not reside on the internal network, so Cloud Shell commands cannot resolve this DNS entry. A virtual machine (VM) within your project can access the private zone DNS. A virtual machine named apigeex-test-vm was automatically created for this purpose. You can make API proxy calls from this machine.
The curl command will be used to send API requests to an API proxy. The -k option for curl tells it to skip verification of the TLS certificate. For this lab, the Apigee runtime uses a self-signed certificate. For a production environment, you should use certificates that have been created by a trusted certificate authority (CA).
In Cloud Shell, open a new tab, and then open an SSH connection to your test VM:
The first gcloud command retrieves the zone of the test VM, and the second opens the SSH connection to the VM.
If asked to authorize, click Authorize.
For each question asked in the Cloud Shell, click Enter or Return to specify the default input.
Your logged in identity is the owner of the project, so SSH to this machine is allowed.
Your Cloud Shell session is now running inside the VM.
The API key may be retrieved directly from the app accessible on the Publish > Apps page. It can also be retrieved via Apigee API call.
In the Cloud Shell SSH session, run the following command:
This command retrieves a Google Cloud access token for the logged-in user, sending it as a Bearer token to the Apigee API call. It retrieves the retail-app app details as a JSON response, which is parsed by jq to retrieve the app's key. That key is then put into the API_KEY environment variable, and the export command is concatenated onto the .bashrc file which runs automatically when starting a the SSH session.
When a POST /orders payload exceeds the limits specified in the JSONTP-Protect JSONThreatProtection policy, the error should now be simpler.
In the Cloud Shell SSH session, execute this curl command:
This payload contains an array with four product objects, but only three array elements are allowed by the JSONTP-Protect policy.
If you rewrote the error message correctly, this clean error message should be displayed:
Your fault rule is not successfully rewriting the error if your error looks like this:
When the Content-Type header is not application/json, an error should be returned.
Test the call without a Content-Type header:
The proxy should now return a 400 Bad Request error, indicating that the Content-Type header must be application/json:
If you use the debug tool to debug the proxy, the result is that the RF-InvalidContentType RaiseFault policy returns the error, and the JSONThreatProtection policy does not run.
When a request does not match any existing conditional flows, a 404 Not Found error should be returned.
Test an invalid API request:
You should receive a 404 error:
In this lab, you learned how to handle faults and manually raise faults.
When you have completed your lab, click End Lab. Google Cloud Skills Boost removes the resources you’ve used and cleans the account for you.
You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.
The number of stars indicates the following:
You can close the dialog box if you don't want to provide feedback.
For feedback, suggestions, or corrections, please use the Support tab.
Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.
Questi contenuti non sono al momento disponibili
Ti invieremo una notifica via email quando sarà disponibile
Bene.
Ti contatteremo via email non appena sarà disponibile
Un lab alla volta
Conferma per terminare tutti i lab esistenti e iniziare questo
