Implementation Best Practices

Document created by treki03 Employee on Apr 20, 2012Last modified by treki03 Employee on Jun 13, 2014
Version 12Show Document
  • View in full screen mode

<<TableOfContents>>

Policy Naming Conventions

When the number of Policy Xpress rules grows over a certain limit or as memory fades, it becomes difficult to identify which Policy XPress rule has performed an update or transformed an attribute.  To assist with this challenge the following naming convention should employed:

Category Management

  • PX001-PX099 Feed / Onboard / Off-board Access
  • PX100-PX199 LAH Conversion
  • PX200-PX299 BLTH Conversion
  • PX300-PX399 Batch File Conversion
  • PX400-PX499 Endpoint Management
  • PX800-PX899 Transformation Logic
    • Ensures that priority is high when using the GoTo Flow control. GoTo skips all priorities before it.
  • PX900-PX999 Failure Handling
  • PX500-PX799  Open

Stack management

One Policy Xpress rule may not be enough to satisfy the business logic that is captured.  A way to manage this business logic is to introduce additional Policy XPress rules for the same Step.

  • PX#.00  is used for initialization, including system variables and data gathering, for the entire Step.
  • PX#.01-99 is used for all business logic within the Step.  For performance reasons, assign only write operations to system variables.
  • PX#.100 is reserved for all write operations to CD/endpoints/External SQL/LDAP.  Write operations are executed as part of a queue.  IMPACT:  Only one Modify User Event will be generated due to this Policy Xpress rule (as opposed to many during the execution of the Step.)  Use system variables (event PX) or LSAs (task PX) to store values.

Standardize Environmental Factors

When migrating an environment from development to staging to production, you may have a challenge due to hard coded values. For example, hostnames or service account names in the Policy Xpress element or action rules that are unique to one environment. To assist with this challenge, consider the following:

  • Use the object store as a place holder (key value pairs only.)
    • Environmental Table
    • dbo.IM_ENVIRONMENTAL_JDBC_LD
  • Set Explore and Correlation generic names in the environment.
  • Set generic hostname for Po.licy Xpress rules (host files or object store.)
    • ADSHost0001 = ads.domain.com
    • SAPHost001 = sap.hostname.com
    • ACF2Host001 = acf2.hostname
  • Set generic service account names for Policy Xpress rules.
    • LDAPserviceaccount001 = cn=ldapadmin001,ou=user,dc=dev,dc=com
    • SQLserviceaccount001 = imdbaadmin
  • Reduce the impact when using Config Xpress

Testing

Using Policy Xpress IS software development, and it requires using a test plan or an automated process to validate the code.

  • Map each Policy Xpress rule to a test plan.
  • Leverage the server logging.jsp and the ims.policyxpress log factory to monitor during testing.
  • Leverage QA reporting tools.

Code Management

Policy Xpress IS software development and requires code/version management.

  • Current Approach: Snapshot the environment to a ZIP file with a date stamp after every update to a Policy Xpress rule.
    • Con: This process is cumbersome and may take more than 45 minutes for a slower development environment on VMware.
    • Con: Policy Xpress rules are not easy to view, and they require a text or XML viewer to sort through the role*.xml file to find the POLICY XPRESS EXPORT sections. Then you must identify the correct Policy Xpress rule.
    • Pro: This process allows for use of the Config Xpress tool to determine deltas between snapshots. One date stamped environment ZIP file is compared to another date stamped ZIP file, and the results is exported out to an XML file.
  • Leverage client’s Source Control Process
1 person found this helpful

Attachments

    Outcomes