Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

How to improve response by distributing static content to remote edge servers

Updated on September 10, 2021

Summary

This article explains how to improve the response of Process Commander applications for remote user groups by caching static content on Web servers local to them (such as "edge" servers) rather than on the server hosting the Process Commander production system.

There are three main steps involved in this process:

  1. Capture static content used by your application on the Process Commander production server in a deployable cache.
  2. Deploy the static content cache on a web server local to your users
  3. Configure Process Commander initialization so that, at login, the remote user's pages are redirected to use the locally cached static content.

Detailed procedures for each of these steps are given in the Suggested Approach section below.

In Process Commander, static content files (image files (JPG, PGN, GIF, SWF), style sheet files (CSS), and JavaScript files (JS)) are stored in the database, for example in Binary file rules and Text file rules. When the rules are called by your application, the static content is cached on the server disk in the StaticContent directory in the Process Commander temporary directory. Later calls to the rules retrieve the static content from the disk cache, saving the time needed to access the database. For more information, see the definition of Static Content in the online help.

Users that are remote from the Process Commander server, for example overseas from the Process Commander site, may still experience a poor response because of slow network connections. The capability described here allows you to create a static content cache for your application that can be deployed to a web server local to these users. You then configure Process Commander so that, at login, these users' environments are initialized to retrieve static content from the local cache rather than the cache on the Process Commander server.

To enable the local static content cache for particular users you create a RuleSet containing the properly-configured initialization activity and then add that RuleSet to the users' Access Group. Because each Access group defines a specific RuleSet List and user role, the static content required for application pages will be different for each access group. For example, users who belong to one access group ("Alpha") may use one version of a JavaScript routine, while users in another access group ("Beta") may execute a different version of that rule or a different rule entirely. As a result,

  • only users that you want to access the local cache should be assigned to the access group, and
  • the procedure to capture static content must be run separately for each access group.

Note: For V6.3 systems, see How to extract and deploy static content to an edge server.

Important:

  • With this process, changes to static content will not be updated automatically. If any content or images are changed for an access group, then the entire capture process must be repeated, and the files reposted.
  • In order to be able to deploy static content on an edge server, all Process Commander applications must use the static JSP tag in HTML references. For details on using the static JSP tag, reference on-line help.
 

Suggested Approach

1. Collect Static Content

Use the following process for each access group for which static content will be captured.

Note: if you have already generated the contents of the RemoteWebServerFiles folder and you specify a different access group, the current contents of the folder will be replaced with that of the new access group. Be sure to back up or copy the files into subfolders on your remote server before repeating the capture process.

  1. Identify the access group for the remote users.

    This access group should contain production operators, and must not contain developers whose Operator ID record allows them to check out rules. Users that can check out rules have a different RuleSet list, and so a different access group "hash" value, than basic users.

  2. Enable the static content capture by temporarily adding the following entries to your prconfig.xml file:

    <env name="http/StaticContent/enableCapture" value="true" />

    <env name="http/StaticContent/remotewebserveraccessgroupname" value="accessgroup" />

    Replace the accessgroup value with the name of the access group for which the content is to be captured.

    For information about editing your prconfig.xml file, see How to change prconfig.xml file settings.

  3. Stop and restart the system to make these changes effective.
  4. Clear the browser cache of your client computers.

    You must clear the browser cache so that the static content will be regenerated with the copies for the remote server. If the local cache is not regenerated, the remote cache will not be created.

  5. Operate your system normally for a day or several days. Be sure to create at least one of every work type in your application, and execute all the user interface functionality.

    The system automatically makes a copy of each static content file (from binary file rules and text file rules) in the RemoteWebServerFiles subdirectory of the ServiceExport directory. Images are stored in a folder called Images, and JavaScript and CSS files are in a folder named webwb.

  6. When the capture is complete, edit prconfig.xml again to remove the StaticContent elements.

2. Deploy the Static Content to a Remote Web Server

  1. Identify the host name, TCP/IP port, and URL path of the edge server to which you wish to deploy the static content.
  2. Copy all folders and files from the RemoteWebServerFiles directory on your application server to a web-accessible directory on your remote web (HTTP) server.
  3. Verify that the files you just copied can be read, by entering a URL address into a web browser to try to read one of the files.

    URL: http://hostname:port/path/ReadMe.txt

    where:

    • hostname is the name or IP address of the edge server
    • port is the port number of the HTTP (edge) server
    • path is the directory where you placed the static content folders on the server

     

    Example: http://myserver:7070/prpc_images/ReadMe.txt

3. Configure Process Commander to Access Static Content on the Remote Server

Process Commander provides an activity, Code-Security.ApplicationProfileSetup, which is called at startup to add additional startup processing. In this step, you configure this activity to specify the location of the static content on the remote server.

Since the static content being deployed is only valid for the users in one access group, you first create a RuleSet version separate from the existing application RuleSets to hold the activity, and then add that RuleSet version as a Production RuleSet to the Application Definition and the specified Access Group. (For details on Production RuleSets, see How Process Commander Assembles an Application RuleSet List.)

To identify the different kinds of static content, set three properties in the ApplicationProfileSetup activity:

  • .pyStaticServerJS
  • .pyStaticServerCSS
  • .pyStaticServerGIF

You set these properties to the path of the static content on the remote server at both at the Requestor level and the Thread level.

To complete this procedure perform the following steps:

  1. Create a new RuleSet and RuleSet Version which are separate from the existing application RuleSets.
  2. Copy the (empty) standard extension point activity Code-Security.ApplicationProfileSetup to the new RuleSet Version. Do not change the name or class it is defined on.
  3. On the Pages & Classestab, enter the Page Name and select the classes for the Thread and Requestor pages:
    Page NameClass
    pxThreadCode-Pega-Thread
    pxRequestorCode-Pega-Requestor

  4. On the Steps tab, delete the placeholder Java step.
  5. Add a Property-Set method and set the three property values on the pxThread page to the appropriate path:

    PropertiesNamePropertiesValue
    pxThread.pyStaticServerJSEnter the URL of the static cache on the remote server. This will be the same URL you tested in Step 2-c above.
    pxThread.pyStaticServerCSSEnter the URL of the static cache.
    pxThread.pyStaticServerGIFEnter the URL of the static cache.
  6. Add a second Property-Set method and set the three property values on the pxRequestor page to the appropriate path:

    PropertiesNamePropertiesValue
    pxRequestor.pyStaticServerJSEnter the URL of the static cache on the remote server. This will be the same URL you tested in Step 2-c above.
    pxRequestor.pyStaticServerCSSEnter the URL of the static cache.
    pxRequestor.pyStaticServerGIFEnter the URL of the static cache.
  7. Save the activity.
  8. Add the RuleSet Version containing the edited ApplicationProfileSetup activity to the Application Rule definition as a Production RuleSet.

    1. Edit the Access Group for which the static content was collected, and add the Production RuleSet.

  9. Test your setup.
    1. Login in to Process Commander as a user associated with the appropriate Access Group.
    2. Clear your client browser cache. For example, in Internet Explorer 7, select Tools > Internet Options. Then under Browsing History click Delete, and the under Temporary Internet Files, click Delete Files.
    3. Using an HTTP "sniffer" program such as Fiddler 2 (from WWWwww.fiddler2.com), verify that the static content is being served from the edge server.

Related Topics

Thirty-three favorite free (or cheap!) developer aids and add-ons

Tags

System Architect System Administration

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us