In this lab, you use the ResponseCache policy to cache entire responses and the LookupCache and PopulateCache policies to cache data.
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 ResponseCache policy to cache getProductById responses.
Product catalogs are often a good use case for response caching, because the information is fairly static.
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 11.
In the Navigator menu, click Proxy endpoints > default > getProductById.
On the Request getProductById flow, click Add Policy Step (+).
In the Add policy step pane, select Create new policy, and then select Traffic Management > Response Cache.
Specify the following values:
| Property | Value |
|---|---|
| Name | RC-ProductsCache |
| Display name | RC-ProductsCache |
Click Add.
Click Policies > RC-ProductsCache.
Replace the ResponseCache configuration with:
There is a single key fragment, the proxy.pathsuffix variable. This variable includes the product ID. Typically, more cache key fragments will be necessary to ensure that the correct response is returned for a specific request.
The TimeoutInSec element overrides the expiration time for the ProductsCache cache by specifying 600 seconds, which is equal to 10 minutes. Responses that are cached will remain in the cache for 10 minutes.
SkipCacheLookup and SkipCachePopulation are both set to skip when the request is not a GET. This is a best practice.
In the Navigator menu, click Proxy endpoints > default > getProductById.
On the Response getProductById flow, click Add Policy Step (+).
In the Add policy step pane, for Select existing policy, select Traffic Management > RC-ProductsCache, and then click Add.
The policy is now attached to both the Request and Response for getProductById. The policy must be attached twice: once in the request flow, and once in the response flow.
Click Save, and then click Save as New Revision.
In this task, you use the LookupCache and PopulateCache policies to cache data from an external service.
In the Navigator menu, click Proxy endpoints > default > getStoreById.
On the Response getStoreById flow, click Add Policy Step (+).
In the Add policy step pane, select Create new policy, and then select Traffic Management > Lookup Cache.
Specify the following values:
| Property | Value |
|---|---|
| Name | LC-LookupAddress |
| Display name | LC-LookupAddress |
Click Add.
Click Policies > LC-LookupAddress.
Change the LookupCache configuration to:
This policy looks in the cache for an entry matching the latitude and longitude and assigns it to the variable address.
In the Navigator menu, click Proxy endpoints > default > getStoreById.
On the Response getStoreById flow, click Add Policy Step (+).
In the Add policy step pane, select Create new policy, and then select Traffic Management > Populate Cache.
Specify the following values:
| Property | Value |
|---|---|
| Name | PC-PopulateAddress |
| Display name | PC-PopulateAddress |
| Condition | lookupcache.LC-LookupAddress.cachehit == false |
The condition skips cache population if the address was found in the cache.
Click Add.
Click Policies > PC-PopulateAddress.
Change the PopulateCache configuration to:
This policy populates the value stored in address into the cache with a key combining the latitude and longitude.
In the Navigator menu, click Proxy endpoints > default > getStoreById.
Move the LC-LookupAddress step to precede the ServiceCallout policy (SC-GoogleGeocode), and move the PC-PopulateAddress policy to precede the JavaScript policy (JS-AddAddress).
After the latitude and longitude are extracted from the backend response, the LC-LookupAddress policy will look for a matching entry in the cache. If a matching entry does not exist, the API proxy should call the ServiceCallout and ExtractVariables steps to get the address from the geocoding service. If the address was not in the cache, the PC-PopulateCache policy will put the address in the cache so that it can be used for the next request of the same store.
If the address is found in the cache, the ServiceCallout, ExtractVariables, and PopulateCache steps should all be skipped in the proxy flow.
Add the following condition:
to the SC-GoogleGeocode and EV-ExtractAddress steps. You added it to the PC-PopulateAddress step when you created that policy. You can detach and reattach those policies, but it is easier to update the default proxy endpoint XML.
Make your getStoreById flow look like this:
lookupcache.LC-LookupAddress.cachehit is a variable set by the LC-LookupAddress policy that specifies whether an entry was found in the cache. If the entry is found in the cache, the variable value is set to true, and the ServiceCallout, ExtractVariables, and PopulateCache steps will be skipped.
Click Save, and then click Save as New Revision.
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.
In this task, you use the debug tool to validate that the caching policies are working correctly in the API 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.
In the Cloud Shell SSH session, to retrieve a specific product by ID, execute this curl command:
The debug tool will show that there was a cache miss and that the backend target was called:
Make the same request again:
This time, the debug tool will show that there was a cache hit and that the backend target was not called:
You can see that the elapsed time for the cache hit call is significantly shorter than that for the cache miss, because the backend service does not need to be called.
In Cloud Shell, to retrieve a specific store by ID, execute this command:
The debug tool will show that all of the steps to call the geocoding service were called, because the store address was not found in the cache.
Make the same request again:
This time, the debug tool will show that there was a cache hit and that the ServiceCallout, ExtractVariables, and PopulateCache steps did not need to be called.
In this lab, you learned how to use the ResponseCache policy to cache responses and how to use the LookupCache and PopulateCache policies to cache other data.
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.
Este contenido no está disponible en este momento
Te enviaremos una notificación por correo electrónico cuando esté disponible
¡Genial!
Nos comunicaremos contigo por correo electrónico si está disponible
Un lab a la vez
Confirma para finalizar todos los labs existentes y comenzar este
