Asynchronous Data Page – its Configuration, Usage & Execution
Asynchronous Data Page

Asynchronous Data Page – its Configuration, Usage & Execution

Summary:

This article discusses the usage of asynchronous data page & how to configure it.

Before reading this post, we suggest you go through our previous post on Data Page that covers all the basics.

How to Refer a Data Page?

We have discussed a lot about configuring the data pages in the previous post. Let’s now quickly see what is the syntax to reference a data page & in what all possible ways we can refer data page in Pega.

Syntax to refer a Data Page

Page

For Example,
1) D_CustomerInfo.FirstName -> Data page without any parameters.
2) D_CustomerInfo[CustomerID:Param.ID].FirstName -> Data page with single parameter.
3) D_CustomerInfo[CustomerID:Param.ID,Status:”Active”].FirstName -> Data page with multiple parameters

Page list

For Example,
1) D_AddressList.pxResults(1).City-> Data page without any parameters.
2) D_AddressList[AddressType:Param.Type].pxResults(1).City-> Data page with single parameter.
3) D_AddressList[AddressType:Param.Type,IsActive:”Yes”].pxResults(1).City-> Data page with multiple parameters.

Referring a Data Page

  • Data page can be referenced in activity, data transform, flow connectors, validate rules, etc.
We need to make sure we pass the correct parameter values when referring a parameterized data page
  • Data page can be referenced to source repeating layouts, to source a section using page context, source a property.
Defer load is recommended to render a section that has reference to the data page which takes a longer time to load. This ensures the UI is not blocked or delayed at run-time.
Repeating layouts can only be sourced with Page list structure data page
  • Data page can be referenced using JAVA/JSP code in the paragraph, correspondence, non-auto generated HTML sections, edit validate, etc.
Referring Parameterized data page of Page structure using JAVA code
Referring Parameterized data page of Page List structure using JAVA code

What is Asynchronous mode?๐Ÿ˜ณ

In general terms, Synchronous means that we can execute only one process at a time. Asynchronous means that we can execute multiple processes at a time which does not have any dependency.

Synchronous mode of execution
Asynchronous mode of execution

We are done with the basics. Let’s now switch gear directly to actual content of the post.

Data Page Asynchronous Execution

In certain situations, data page execution might take time and we can’t make the current execution wait till the completion of the data page load. ๐Ÿ˜’

Wouldn’t it be good if we can trigger the data pages execution in a background mode and make the page readily available when required?๐Ÿ˜ณ

Yeah, Data pages can be loaded asynchronously using activity methods Load-DataPage & Connect-Wait ๐Ÿ˜Š

Load-DataPage

  • This method is used to trigger (Queue) the data page execution in asynchronous mode.

Parameters

This method has 3 parameters,

  • Pool-ID: In Asynchronous mode, each execution will happen in a separate child requestor in the background. Pool-ID mentioned here is used to keep track of the requestor information & to group all rules queued for asynchronous execution. Pool-ID can be any random value of our choice.
  • Data Page: Name of the data page that needs to be queued for execution.
  • Params: This is applicable only if the specified data page is parameterized. The values mentioned here will be used to run the data page in the background mode.

Connect-Wait

  • This method is used to ensure the execution of the queued data page is complete and make it ready for access.

Parameters

  • Wait seconds: We can enter an integer value here till which this method should wait for the child requestors to complete. If the mentioned wait time is crossed, an error status will be returned. The value can be left blank if the system need not wait or -1 if the system should wait for an indefinite time [till the completion of all child requestors].
  • Pool-ID: Pool ID that we have used during the Load-DataPage should be mentioned here. This method ensures that all the child requestors whose Pool-ID values match this input are returned back.

Let’s implement the below scenario to understand the asynchronous execution of the data page in detail.

Business Scenario

OSP organization has a claims application to process the reimbursement request submitted by Customers. Each claim request should have information about the Customer and associated addresses before processing the claim.

Implementation

  • Let’s create 2 different data pages to fetch Customers and address information based on the customer id.
  • Just to queue the data page execution, run an activity with the Load-DataPage method during the creation of each claim case. NewDefaults can be specialized in claims work class to implement this.
  • Now in between the flow when the data page information is needed, just run a connect-wait method to load the data page results and keep it ready for access.
  • Once the connect-wait method retrieves & loads the data pages, it can be referred wherever required based on the scope of the data page.

What happens at the back-end?

  • Whenever the Load-DataPage method gets invoked, the system creates a separate requestor and queues the execution of the data page.
Each Load-DataPage will have a separate requestor created.
  • As a result of this, Pega creates different requestors and executes the data page. The number of idle requestors, active requestors, and other information can be seen in the Admin studio requestor pools.
Requestor pool in Admin studio
  • Created child requestors will execute the data page and keep the results ready. Connect-Wait method when used will invoke all the requestors belonging to the mentioned Pool-ID and loads the information back to the current thread/requestor.

How to debug asynchronous execution?

  • To debug asynchronous execution, enable the below settings in the tracer rule.
  • Now in the tracer event, click on the ADPLoad in the event type column of the Load-DataPage step and we would be able to see the execution of the data page in asynchronous mode.
  • Each Load-DataPage call will create a requestor at the back-end. Requestors will be active until consecutive connect-wait method retrieves information pertaining to that pool-ID.
  • The maximum number of active requestors allowed for queue execution is 50 by default. If our Load-DataPage execution happens when there are already 50 active requestors (full) in the pool, then our current request will be processed synchronously.
  • Requestor configuration can be updated in the OOTB service package AsyncDeclarativePool based on the business need.

How to clear the requestor pool of the AsyncDeclarativePool Service Package

When the maximum number of the active requestors is reached during development phase, we can manually clear/kill them off with the below methods.

  • Switch to the Admin studio and open the requestor pool of the AsyncDeclarativePool package and clear the requestor pool.

    Admin Studio -> Resources -> Requestor Pools
  • We can also hit the below Pega API to clear the requestor pool for the given Node and Service package.

Pointers to Remember when using Load-DataPage & Connect-Wait

  • Load-DataPage is preferred only when the data page is queued [Load-DataPage] and accessed [Connect-Wait] in the same scope.

For example:

  1. For the thread-level data page, if the Connect-wait method is not used in the same thread as that of Load-DataPage, then the asynchronous execution will be ignored.
  2. For the requestor-level data page, if the Connect-wait method is not used in the same requestor as that of Load-DataPage, then the asynchronous execution will be ignored.
  • Queued data page can be used for reference only after using the connect-wait method. If not, it will be considered as a fresh invocation and will be executed synchronously.
Referring the data page immediately after the Load-DataPage is not correct
Referring the data page after connect-wait method is recommended.
  • When Load-DataPage is invoked for the data page which is already queued for execution, the PEGA0045 alert will be thrown at the back-end.
  • Data page which is queued for execution can be referenced in sections if defer load enabled. When defer load is not enabled in section, then queued items will be ignored and the load will be synchronous.
  • Asynchronous data pages cannot run declarative expressions, triggers, and other rules that belong to a declarative network.
This expression will not be fired if D_SurveyScore is loaded asynchronously
  • Since the asynchronous data page is executed in a separate requestor, the user pages required for processing from the current requestor context will not be readily available unless we define those pages in the pages and classes tab of the data page rule. When defined, Pega copies the required pages to the background requestor and completes the processing.
When D_CustomerInfo is queued for execution, pyWorkPage of the current thread will be copied to the background requestor and will be available for its processing.
  • We can disable asynchronous data page execution by setting the below variable to false in prconfig.xml or by creating DSS for the same.
<env name=" initialization/asyncdeclarepages " value="false" />
  • When this variable is set to false, the data page irrespective of how it is triggered [Load-DataPage] will be executed synchronously.

Now we are at the end of the post. Hope this post gives you an understanding on Asynchronous data page and how carefully we should use it.

Stay tuned for lot more posts on Data Pages ๐Ÿ˜Š

OSP TEAM
Written by
OSP Editorial Team

Recent Jobs from our community

loading
View more Jobs on OSP Forum
Join the discussion

Feel free to post your questions here about this topic if any. We will definitely get back to you ASAP !!!
If you have any off-topic questions, Let's discuss at OSP Forum

18 comments
  • Hi Team,
    Could you please elaborate further these statements in the above example:

    For the thread-level data page, if the Connect-wait method is not used in the same thread as that of Load-DataPage, then the asynchronous execution will be ignored.
    For the requestor-level data page, if the Connect-wait method is not used in the same requestor as that of Load-DataPage, then the asynchronous execution will be ignored.

    • We all know that scope of a data page can be thread, requestor or node.

      Load-DataPage will queue the execution of the data page in the asynchronous mode and Connect-wait will load the data pages results back from the asynchronous execution.

      Scenario 1: Let’s say you queue a thread-level data page in thread1 using Load-DataPage and use connect-Wait in a thread1 [same thread], then the queue item will be available and data pages will be loaded asynchronously.

      Scenario 2: Let’s say you queue a thread-level data page in thread1 using Load-DataPage and use connect-Wait in a thread2 [different thread], then the queue item will not be available since the queue didn’t happen for thread2. Hence data pages will be loaded synchronously in thread2.

      The same applies to the requestor-level data page as well.

      Let us know if you still have any questions. We will be happy to help you make understand it with different examples if required.

  • Nice post team.. Few queries:

    1) What happens if we do not specify the Pool Id while loading the data page? will it be loaded in the same requestor/thread?
    2) Can node level data pages be used with this method for improving system performance?

    • Happy that you liked our post.

      1) When Pool iD is not mentioned, the system generates a unique id and uses that for queueing. When you use the connect-Wait method with an empty Pool ID, then the system retrieves the requests queued with the system generated Pool ID. The systematic generation of Pool ID depends on the scope of the data page rule.
      2) Yes, Load-DataPage can be used for Data Pages with Node scope. In that case, the Connect-Wait method can be used in any requestor and any thread under the particular node.

      Happy Learning from OSP ๐Ÿ˜Š

  • What happens if we Load the DataPage asynchronously during case creation using Load-DataPage method and giving it enough time to load and use the DataPage as source for a repeating grid present in the last screen of a case. Do we still need Connect-Wait method ? Connect-Wait is usually used by RDB and Connect methods to wait for complete execution of child requestors right. Not to copy the results from child requestors to parent right?

    • In this scenario, we can either use connect-wait or we can also use the defer load option in the layout. Defer load option in the layout first checks for any ADP requests for the data page and if not found, it loads the data page freshly. This is called as non blocking UI in Pega.

      • Can you please provide clarification on the below :
        Connect-Wait is usually used by Async Datapages, RDB and Connect methods to wait for complete execution of child requestors right. Not to copy the results from child requestors to parent right?

  • Good job Team. I am learning new topics from your published articles.
    I have one doubt.
    Lets assume I have used Load-DataPage method to load the data asynchronously.
    Will the child requestors will be in active state until and unless it comes across the Connect-Wait method using that pool ID?
    Or
    Will Child requestors get in to Idle state once the execution of Data page is completed?

  • nice post.. can you please explain how to use connect-wait method to wait for completion of queued batchactivity (on child requestors)

    • Hi Jagadish, I think it is not possible. It can only be achieved by an Activity. reason being, we need to use the :Load-DataPage’ method for asynchronous processing.

    • Hi Sowjanya,
      Asynchronous loading of Data page is not possible with Data transform. It can be achieved in an activity by using Load-DataPage method or maybe by customized Java code.
      For loading a normal data page we can reference it in Target or source property of Data Transform. Ex: D_ABC[xyz:value] xyz- parameter defined in data page

  • hi,
    If I want to pass any information from the child requestor to the parent requestor, how to do that? For example, If the D page got some error code and i want to get that error code in the parent requestor, apart from using system pages(which is not recommended), what else we can do? Editable requestor level D page did not help and Read-only Requestor level D page cant be used.