Self-discovering and troubleshooting Constellation behavior

1. If you have sufficient privileges to add extensions to your preferred web browser, install the Redux DevTools extension.

   The following table contains links to the extensions for your preferred browser:

   Browser	Details
   Google Chrome	Go to the Chrome Web Store.
   Mozilla Firefox	Go to the Extension page of Add-ons for Firefox.
   Microsoft Edge	Go to the Edge Addons site.
   Safari	Redux DevTools extension is not available. Use another browser to use this tool.

2. After installation, pin the extension to any extension toolbar in your browser so that it is easily accessible.

Compared with traditional UI applications, Constellation UI applications make a larger number of more granular DX API calls. These exchange structured data payloads in JSON format are used to submit data updates to the Pega Infinity™ server and gather the data that Constellation uses to draw the user interface.

The latest versions of the four browsers supported by Pega Platform (Chrome, Firefox, Edge, and Safari) all have a built-in Developer Tools (or "DevTools") feature.

1. Locate the Developer Tools feature for your browser.
   Note: This feature might be in a More Tools submenu. Note the keyboard shortcut and practice using it.
2. Open DevTools.
   
3. In DevTools, click the Network tab, and then click the Fetch/XHR filter.
   Note: In the following figure, the purpose of the Network tab (1) is to show all network interactions issued by the browser. Self-discovering Constellation begins with observing the DX API calls made by Constellation and then observing the JSON data that is exchanged in each of them.
   
   The Fetch/XHR filter (2) is useful for showing the DX API calls without showing other types of content retrieved by your browser. On the left of item 3 is a Clear icon that removes all the events captured on the Network tab. Familiarize yourself with this icon because you will use it often.
   
   Note: XHR is an abbreviation for XMLHttpRequest, an underlying library that client-side code uses to perform ad-hoc HTTP requests when running code.
4. In the Pega Platform instance for the challenge, enter the following credentials:
   1. In the User name field, enter Troubleshooter@LMKT.
   2. In the Password field, enter pega123!.
5. Keep DevTools open and focused on the Network tab, filtered by Fetch/XHR, and then clear any existing events.
6. In App Studio, click Preview.
7. On the Network ​​​​​​tab, click the WebPortal event.
8. Explore the following tabs on the pane that is displayed, which shows more detail about the WebPortal interaction:

   Network Request tab	Relevant data elements	Purpose
   Headers	General - Request URL	The full URL of the DX API request issued by Constellation
   	General - Request Method	GET - record retrieval (no request payload) POST - record creation; data retrieval with request payload PATCH - record update
   	General - Status Code	2xx, 3xx: Success 4xx: Security failure, Bad request, or Resource Not Found 5xx: Server run error (likely in the Pega Infinity server)
   	Request Headers - Cookie	Pega-AAT: DX API "Authorized Access Token" Pega-RULES: Standard H-requestor cookie
   Response		Raw JSON response returned from DX API
   Preview		Tree-style navigation of the Response content
   Cookies		The cookies used in this interaction are shown as a table

9. Use the following table to explore interesting DX API operations and self-discover which DX API calls influence key elements of the Constellation UI.
   Use the Preview tab of each item to jump to the interesting data item.

   Network tab event	Preview tab item	Significance to Constellation UI
   WebPortal	data.pyPortal.pyPrimaryNavPages	Landing pages shown in the left navigation pane
   pyHome	data.D_pyAnnouncements	Announcements pane content
   D_pxAvailableCaseTypesForPortal	pyCaseTypesAvailableToCreate	Case Types that you can create
   Other D_xxxxxxxx		API calls to retrieve list data page content, including: D_pyMyFollowedCases D_pyMyWorkList
   	data	Data Records from the Data Page
   	totalCount	Number of records in the Data Page
   	queryStats	Data source type and run time

10. On the D_pyMyFollowedCases interaction, review the new Payload tab.
    D_pyMyFollowedCases is an HTTP POST operation that sends JSON data to the request body. Similar to the Preview tab for the request, the Payload tab provides a tree navigation of the JSON data sent in the request. The Payload tab shows:
    • There are no values sent for dataViewParameters.
    • A paging object is sent to instruct DX API on what page of a large result set is requested.
    • A query object is sent to instruct DX API on how to adapt the query that the data view runs on the Pega Infinity server.
    Tip: When troubleshooting a discrepancy on the Constellation UI, locating the relevant DX API call and inspecting its request and response is useful. It helps you understand:

    • The DX API operations that Constellation is orchestrating for the current UI.
    • The data sent to and returned from the Pega Infinity server.
    Note: It looks like there is a DX API endpoint for running Data Pages.

    • How do you feel about that?
    • Should this be secured in some way?
11. Clear the Network tab, leave it open, and then create a Customer Intake Case.
    Tip: Eventually, you will notice the following messages are displayed on your Network tab. This is fine and normal. Constellation is silently refreshing your authenticated access token, which has expired according to the period configured in the OAuth 2.0 Client Registration record of your application.

    

    A normal sequence is:

    1. Request A fails with a response code of HTTP 401 (Unauthorized).
    2. Constellation reacts by invoking the updateSession API. An HTTP 200 response contains a replacement Access Token, which Constellation uses for future DX API requests.
    3. Request A is replayed with the new Access Token and issues an HTTP 2xx response code when it is successful.
    4. All subsequent requests are expected to be successfully authorized until the new token expires.
12. On the Network tab, inspect the (successful) cases?viewType=page event.
13. Review the Payload tab and the following information sent by Constellation when requesting the creation of a new Case:
    1. The class and starting flow.
    2. An empty content object.
    3. The Preview tab, which shows, among a range of other interesting values, that the Pega Infinity server has responded with:
       • ID: The pzInsKey of the Case.
       • data.caseInfo.assignments: Information about the Assignments available for the user to perform.
       • data.caseInfo.availableActions: The list of alternate Actions that are available at this Stage in the workflow.
       • Remainder of data.caseInfo (including data.caseInfo.content): The latest Case values that the Constellation UI might need to show on the current UI.
    Tip: The first screen on the Case workflow only shows Loan Purpose and Requested Amount. However, data.caseInfo also includes the following information. Can you think why?

    • content
      • Applicant.pyLastName
      • GuarantorCount
    • createTime
    • createdBy
    • lastUpdateTime
    • lastUpdatedBy
    • status
    • urgency

    
    When authoring the application in an earlier challenge, was there one place where you referenced these fields?
    Tip: Although there is sometimes a data.pyWorkPage element in the DX API response, consider data.caseInfo and data.caseInfo.content as DX API's closest equivalent of pyWorkPage.
    
    You soon observe that there is never a complete pyWorkPage that passes over DX API or is managed in the browser. This is intentional.
14. Clear the Network tab, enter values into the Case UI, and then click Next to submit the Assignment.
15. Observe the following details about the next event logged on the Network tab:
    1. The HTTP method and URL of the DX API call is PATCH .../assignments/.../actions/Create?...
       This means "update [perform] the existing assignment with ..." the information provided in the request
    2. The Payload tab shows the data you entered is sent with the DX API call that performs the assignment​​
    3. The Preview tab, specifically, data.caseInfo, shows field values that need to be updated in the client-side model. This information includes default, not-null values for the fields to be shown on the UI of the next Assignment (inside the Applicant embedded object)
    Tip: Look what else you have self-discovered about Constellation by paying attention to what is in the DX API response:

    

    Remember how much you learned about Pega Platform earlier in your career by looking at what the tools told you?
    
    Self-discovery is also possible in Constellation; be looking for new things to learn.

The Tracer tool is still essential for self-discovery and troubleshooting Constellation applications. Constellation includes an architecture shift to stateless DX API calls that, like calls to any Service-REST Rule, each run in its own Requestor. As a result, you use the Tracer differently when authoring your Constellation applications to review the low-level execution steps performed on the Pega Infinity server.

1. In your DevTools, on the Network ​​​​​​tab, clear the events.
2. Keep your Case from the previous task open.
   If you closed it, create a new Case, and then proceed to the Capture Applicant Details Step.
3. Launch the Tracer.
   Note: If this is the first time you have used the Tracer in this instance, remember to look for a Pop-ups were blocked on this page warning. Follow the prompts in your browser to always allow popups from your Pega instance.

   

4. Optional: If your browser launches another window for DevTools that is bound to your Tracer, close the new DevTools window that is launched.
   Leave the DevTools window that is bound to App Studio open.
5. In your Tracer window, edit the settings to match your typical Tracer preferences.
6. Ensure that the following settings are in place:
   1. In the Event types to Trace section, confirm that the Data Pages and DB Query checkboxes are selected.
   2. In the Rulesets to Trace section, confirm that the Pega-Reporting checkbox is clear.
   Caution: If a stream of Data Page events continues to fill your Tracer when it is running, pause, restart, or close and reopen your Tracer until it stops. If nothing else works, turn off the Data Pages event.
7. With your Tracer running, clear the Network tab, and then in the Capture Applicant Details Step, locate the Guarantor Search area.
8. In the First Name field, enter oliver, and then perform the search.
9. On the Network tab, examine the first D_CustomerList API call that Constellation performed:
   1. Confirm that the Payload tab shows what Constellation sent to the Pega Infinity server, and then note the following results:
      • query.select: Instructs DX API on the fields that the UI needs to fulfill the business outcome.
      • query.sortBy: Instructs DX API on how to sort the result set to fulfill the business outcome.
      • query.filter: Instructs DX API on the filtering criteria to apply to the data source of the records. The filter conditions are defined similar to a Report Definition Rule:
        
   2. Confirm that the Preview (response) tab shows what the Pega Infinity server returned to Constellation, and then note the following results:
      • The result set only returns the columns that Constellation asked for (even though more columns are defined in the underlying Report Definition).
      • The result set is sorted in the order that Constellation asked for (even though the underlying Report Definition specified pyGUID as its sort criteria).
      • The result set is filtered to match the search requirements (even though the underlying Report Definition has no filters).
        
10. Pause your Tracer, and then collapse all the blue boxes to observe how Tracer events in Constellation applications are categorized:
    1. Confirm that there is a blue box for each DX API interaction that was performed while your Tracer was running.
    2. For actions that trigger multiple DX API calls, run the Tracer, and then observe that a category appears in the Tracer for each DX API request.
       There might be another blue box for all of the events running against your requestor that are not part of DX API interactions.
       
11. Expand the blue box for D_CustomerList.
    This section shows the events that run on the Pega Infinity server when servicing that specific DX API call.
    Depending on the Tracer events and Rulesets that you have turned on in your settings, the first 400-600 events of each group are related to establishing the requestor for that service call. You can usually ignore these events.
12. Look for Activity End : Code-Security ApplicationSetup.
    Consider this the end of the "bootstrap" phase. Steps that follow the end of ApplicationSetup relate specifically to the DX API service call.
    
    Tip: After the Tracer reaches the service-specific Tracer events, the techniques you have always used for using the Tracer still apply.
13. Starting from the Data Page events logged for D_CUSTOMERLIST, scroll up through the events logged for pxCallRetrieveReportData, and then observe the blue DB Query events.
    These DB Query events show the SQL statements that were executed on the Pega database to retrieve the records included in the response to the DX API call.
14. Click the lowest SQL event where the database table is p_lmkt_customer_data_customer to observe the SQL that was run to perform the search.
    
    Tip: Data Pages can now receive instructions from their caller that allow them to further refine the columns selected, the sort order, and the filters used on the underlying data source. Report Definitions are already capable of adapting the SQL they run to use these caller-provided instructions.
15. In your Case, select two of the results that include Oliver in their name.
16. Leave the current state of your Network tab and Tracer uncleared.
    Run your Tracer if you paused it.
17. Clear your search, then in the Last name field, enter smith, then perform another search.
18. Confirm that the Network tab shows that another D_CustomerList API call was made.
    The Tracer groups the events from the new D_CustomerList API call into a separate blue box:
    
19. Explore the Tracer events of the second D_CustomerList event to observe that different SQL is run for the second search.
    Leave the results that include Smith in their name unselected for now.
20. Clear the Network tab, and then close the Tracer.
    Note: Short-lived, stateless DX API calls can fulfill the data needs of a Constellation UI.

You did not configure any Action Sets. How did Constellation know what DX API calls to make when you clicked the Search button?

The system captured it in the View configuration for the advanced search of the Guarantors data reference, as shown in the following figure:

One of the major shifts brought by Constellation architecture is that client-side code that runs in the user's browser generates the user interface. Constellation uses the collection of data and instructions gathered in DX API responses received from the Pega Infinity server to know what user interface to draw.

Constellation uses a JavaScript library called Redux to manage a model of the data and instructions gathered from DX API in your browser. By caching data received from earlier interactions in a local store, Constellation reduces the number and size of DX API calls that Constellation makes to the Pega Infinity server to draw the UI with up-to-date data. This makes Constellation UIs much faster to render than their equivalent Views in traditional UI.

The Redux DevTools extension provides a way of inspecting the current browser's Redux store. This may be useful when the Network tab and the Tracer cannot show the root cause of a Constellation UI showing incorrect output.

1. Launch the Redux DevTools extension. 
   You can access the extension on the Redux tab in your browser's DevTools, or by right-clicking on the Redux extension, and then selecting Open in a window.
2. Activate the following tabs in order:
   1. Inspector
   2. Diff
   3. Tree
      Explore the other options in your own time.
3. In the left pane, note the @@INIT (4) event in the action list.
   
4. Return to your Case, which shows a list of Customers with the last name Smith.
5. Select the checkbox for Jane Smith, but do not click Next.
6. Check your Network tab to confirm that no API calls have been made.
7. In your Redux DevTools, confirm that the system recorded a LIST_ACTION event in the left pane.
8. Click LIST_ACTION.
   Note: If there are several recent Redux events added to the action log, go to the final LIST_ACTION event at the end of the log.
   On the Diff tab, the Tree tab displays data store changes using a tree structure so that you can see what changed in the local store when that event occurred:
   • The pyGUID for Jane Smith was added to Guarantors[2]. No other changes to the local store were recorded.
   • The Redux store manages its Case data in the caseInfo.content section, similar to how DX API publishes it.
     
9. In the content row, click (pin).
   Click (pin) focuses the Redux DevTools specifically on the caseInfo.content store for the current Case in this and other events in the tool.
10. Click the State tab to see the complete state of the current Case data instead of just the differences between this and the previous event:
    Note: Why do you think GuarantorCount is showing as 0 when the Guarantors list has three members?
    1. Observe that Jane Smith is Guarantors[2] because Guarantors[0] and Guarantors[1] are the two Olivers added from the previous search.
    2. Observe that caseInfo.content in the local store is an aggregate of the latest state of the Case data.
       It merges what has been confirmed as fact from earlier actions and DX API calls (the LoanPurpose and RequestedAmount fields) with what has been newly entered by the user but not yet committed to the Pega Infinity server over DX API (Guarantors 0-2).
       
11. Click the Diff tab.
12. In the toolbar, click Commit.
    Committing re-baselines @@INIT to reflect the current state of the local store. It acts like clearing the Network tab so that you are clear on which Redux events relate to the next actions you take in the application.
13. In your Pega application, click Next to submit the Assignment.
    The Network tab shows the DX API call that sends the newly collected information to the Pega Infinity server.
    1. In the CaptureApplicantDetails call, confirm that the Payload tab shows:
       • The content object that describes top-level and single-page property changes.
       • The pageInstructions object that replays the sequence of ACTION_LIST events for page-list property changes.
    2. In the CaptureApplicantDetails call, confirm that the Preview tab shows:
       • The DX API response that instructs Constellation on what data changes it needs to be aware of.
       • data.caseInfo.content.Finances is staged to be ready to show the default values for the next Assignment's UI.
       • data.caseInfo.content.Guarantors is absent because the Pega Infinity server made no changes to what the browser already has stored.
       • data.caseInfo.content.GuarantorCount is set to 3.
14. In the left pane of Redux DevTools, click each event from top to bottom to see the changes to the Case data that you pinned.
    These are the series of events that have been performed in the local store after clicking the Next button in the application. Only the UPDATE_CONTAINER_ITEM event changes the Case state in the local store.
    • The Finances object attracts the values that were provided by the DX API response.
    • The GuarantorCount value is updated from 0 to 3.
      
15. Click the State tab to compare what is managed in the Redux store with what is transmitted over DX API.

Note: The Redux store caches everything it has seen about the current Case in the current session. As a result, the DX API only communicates changed values and confirms the values needed for the current user interface. This reduces the bandwidth that DX API interactions consume.

The following table shows the DX API response from completing the Assignment and the resulting state of the Redux store:

DX API response from Assignment completion	Redux store state after server round-trip

See how the DX API did not have to return the list of Guarantors in the latest response? The next UI does not reference them. The local store, however, continues to keep a record of what it has seen.

So far in the workflow, DX API calls have happened at the point of creating the Case, submitting Assignments, and performing a search.

In this task, you will observe how Constellation keeps calculated values updated in its local store during the data entry that a user performs. The Network tab in your browser DevTools is the most useful tool for self-discovering how this works, although you might also want to use the Redux DevTools to monitor this as well.

1. On the Network tab, clear the history.
2. In the Income and Expenses section, in the Income lines table, add a new row.
   Note: In the following figure, the Network tab shows that a DX API call to a /refresh API occurs any time a value on the screen changes:

   
3. On the Network tab, explore the response from the /refresh API calls made after each amount value (in either the Income or Expenses rows) changes.
4. Note that the response always contains up-to-date calculations of Total Income, Total Expenses, and Net Income, as shown in the following table:

   User interface showing calculated values	DX API /refresh API supplying calculated values

   Tip: An editable View that includes calculated fields initiates a /refresh API call whenever the value of any editable field on that View changes. Constellation is not aware of the declarative network of a calculated field. Constellation assumes that any field change might invalidate the current calculated values and performs a round-trip with the Pega Infinity server to ensure that the calculations remain synchronized with the latest Case data.
   Caution: Beware of poor-performing declare expressions. Depending on the editable Views on which they are shown, the system might recalculate them frequently in a Constellation application.
   Tip: The /refresh API call is similar to a Section refresh in traditional UI. Consider /refresh as a data refresh rather than a UI refresh.

   • Only JSON data passes over the Constellation DX API. Heavier-weight HTML was sent in the response to traditional UI Section refresh actions.
   • You did not configure any Action Sets to achieve this outcome. Constellation can orchestrate the display of calculated values because of the business outcome that you configured the Data Model to fulfill.

Screens shown to users and developers in traditional UI are generated on the Pega Infinity server. As such, a Studio-based tool such as Live UI can understand the server-generated HTML and highlight the individual building blocks.

However, the HTML for Constellation UIs is generated by React in the user's browser. Live UI cannot completely anticipate the final Document Object Model that Constellation generates in the browser.

The Constellation alternative to Live UI is called X-Ray. It is packaged in the PCore JavaScript library, which is part of Constellation's orchestration layer and operates in the browser of every Constellation application.

1. Ensure that you are in the Income and Expenses Step of your Case.
   If you are not still on the Income and Expenses Step, you can navigate back to it or start a new Case and move forward to that Step.
2. In your browser's DevTools, click the Console tab.
3. Clear any messages in the Console by using the Clear icon.
   
4. Run the following code in the Console to turn on X-Ray:

   PCore.getDebugger().toggleXRay(true);

   Caution: Did you get an error message similar to the following figure?

   

   
   The default context of the Console tab is the top-level document in the current browser tab. When using Preview mode in App Studio, you preview the user channel in an iframe in App Studio. App Studio is not a Constellation application, so there is no PCore global object available to that document.
5. Next to the Clear icon on the Console tab, locate the window selector list, which has the default selection of top:
   1. Click the list, and then scroll through the available windows.
      The options vary depending on the other browser extensions you have installed.
   2. Locate the FormFactoriFrame entry, and then hover over it.
      An overlay might be displayed on your browser that shows the real estate that the window consumes, which confirms that this window is the user channel that you are previewing.
      
   3. In the list, click the FormFactoriFrame item.
6. Run the following code in the Console to turn X-Ray on in the FormFactoriFrame:
   PCore.getDebugger().toggleXRay(true);

   This time, no errors are expected.
    

   Note: Unlike Live UI, X-Ray does not engage until the next time Constellation draws a screen.
7. On the Income and Expenses Step, click Next to open the Capture Employment History Step.
   Tip: Similar to Live UI, the X-Ray tool shows which UI components are used to compose the current user interface.
   Among others, X-Ray shows the relationship between:

   • Template components (Regions)
   • Pega Platform constructs (pzCreateDetails)
   • Implementation team Rules (CaptureEmploymentHistory)

   
8. Experiment with clicking Previous and Next between the Employment History and Income and Expenses Steps.
   After toggling it on, notice how X-Ray remains active for every screen that Constellation draws.
9. Return to the Employment History Step, and then click the Info icon next to View: CaptureEmploymentHistory (item 1 in the screenshot from step 7).
   The window that is displayed shows the low-level UI metadata about the selected component returned from DX API.
   Note that guidance on exploring more information from the console is provided at the bottom of this window.
10. On the Console tab, run $pConnect.
    
    Tip: For every Component drawn on a Constellation UI, the Constellation orchestration layer injects a PConnect instance that describes the current context.
    
    DX Component developers will find this feature very valuable when designing a new DX Component or debugging why an existing DX Component is not behaving as expected in its current context.
11. Click the Info icon for the CaptureEmploymentHistory_EmploymentHistory View (item 2 in the figure from step 7) to observe the different information that it shows.
12. Return to the Console tab, and then run $pConnect again.
13. Observe how its return value aligns with the X-Ray user's current focus item.
14. In your browser's DevTools, click the Network tab, and then clear its contents.
15. While X-Ray remains toggled on, begin adding an Employment History record.
    The dialog box in which you capture the Employment record continues to use X-Ray.
16. Click the Country search box.
    The Network tab teaches us that a D_pyCountryList Data Page provides the list of countries for the Address component. X-Ray also references this Data Page when reviewing the AutoComplete metadata.
    X-Ray confirms to us that the default View for capturing address information is pyAddressForm.
17. In the Country list, select United States.
    X-Ray confirms that pyAddressForm_USA takes over as the View for capturing addresses in the United States.
    The Network tab shows that a D_pyStateList Data Page (which takes a pyCountry parameter) provides the list of states from which users can select.
    Tip: Experiment with other countries to practice using X-Ray and the Network tab together to self-discover and troubleshoot your Constellation applications.
18. Return to the Console tab, and then toggle X-Ray off by running the following code in the FormFactoriFrame window:
    PCore.getDebugger().toggleXRay(false);
    Tip: On the Console tab, use the Up and Down arrows on your keyboard to cycle through past commands.
19. Submit the dialog box, and then advance through the Employment History Step to the Full Page View of the Customer Intake Case.

    Note that X-Ray is no longer running.

While authoring the Capture Asset Details Step in the Adding data references to your Constellation application challenge, there was a problem configuring the Intended Vehicle data reference. Specifically, no Data Pages for the Vehicle Variant data object were displayed, as shown in the following figure:

The developer of the Vehicle module insists that list-style Data Pages exist in this data class.

Use what you learned earlier in this challenge to investigate this problem further.

1. If the current Customer Intake Case has a Vehicle for a loan purpose, continue with your current Case.
   Otherwise, create a new Case, and then in the Loan Purpose list, select Vehicle.
   Tip: Check the Summary panel in the upper left of your current Case to verify the Loan Purpose.
2. Proceed to the Collect Additional Documents Step.
3. In your browser's DevTools, click the Network tab, and then clear its contents.
4. Submit the Assignment.
   
   Note:

   The same screen that had the configuration issue during authoring also incurred a runtime error. Even if the error message does not appear at the top, the absence of vehicles to select suggests a problem.

Apply what you have learned

Using the information available in the Network tab, determine the cause of the error.

Network tab

• Despite the view configuration being blank, Constellation resolved a default list-style Data Page: D_VehicleVariantList. to supply the list of vehicles.
• The /data_views call to that Data Page returns an HTTP 403 (Forbidden) response code, which indicates that the issue:
  • Is an authorization problem
  • Is not an authentication problem (HTTP 401)
  • Is not a problem during Rule execution (HTTP 5xx)
• The response states, "User is not allowed to access or update the resource."
  • DX API knows who the user is.
  • DX API knows what the resource is.
  • DX API forbids user access to the resource.

Make the following considerations before proceeding with the fix in this task:

• In what Application Layer is the defective Rule?
• Should the implementation of the fix occur in the same layer?
• If the developer was unaware of this security restriction, might other Rules be affected by the same defect?
• Who is responsible for fixing this defect?
• If you are going to implement the fix this time, how do you use Branch Development Preferences to ensure the fix gets merged into the best Ruleset?
• How is the fixer going to verify the fix?

1. Open Branch Development Preferences, and then create a new Branch.
2. Select the Application Layer that contains the Rulesets into which to merge the fixed Rules, and then click Submit.
3. Implement the fix for all affected Rules in the appropriate Studio.
   
4. In DevTools, open the Network tab, and then re-open the earlier Case on the Capture Asset Details Step.
   The Intended Vehicle list now shows results to select:
   
   The Network tab shows HTTP 200 for the Data Page lookup instead of HTTP 403:
   
5. In Dev Studio, in the App Explorer, click the Branches tab, and then open the Branch used for this fix.
   Confirm that the Rules modified in this fix apply to the expected class and Ruleset.
   

The Vehicle Variant Data Pages issue also blocked the View configuration of the Intended Vehicle data reference.

1. Return to the View for the Capture Asset Details Step.
2. Configure the Intended Vehicle data reference field:
   1. In the Display as list, select Advanced search.
   2. In the "Search for" categories section, add the following fields:
      • Make
      • Model
      • Year
   3. For the Year field, clear the Show thousands separator checkbox.
   4. In the Columns section, add the following columns:
      • Make
      • Model
      • Category
      • Year
      • Price
   5. For the Year column, use an integer format, and then clear the Show thousands separator checkbox.