000031811 - Some RSA Via Lifecycle & Governance 6.8.1 and 6.9.1 patches take longer to apply

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000031811
Applies ToRSA Product Set: RSA Via Lifecycle and Governance, Identity Management and Governance (formerly Aveksa)
RSA Version/Condition: 6.8.1 P17, P18, P19, and P20; 6.9.1 P04, P05, P06, and P07
IssueThe installation of patches, starting with 6.8.1 P17 and 6.9.1 P04, might require additional time to apply due to a change that was made in the persistence of workflow metadata.
This additional time, which may be significant, is required to verify that the appropriate configuration data is stored in the workflow to ensure consistency during the import/export process. The amount of time needed for this process is dependent on the complexity of the workflows.
CauseStarting with 6.8.1 P21 and 6.9.1 P08, a table modification has been provided which helps improve the workflow migration significantly, however, the application of the patch will still be longer based on the number of workflows. 
This code change is needed to verify that the appropriate configuration data is stored in the workflow to ensure consistency during the import/export process.
ResolutionThe time to apply the patch could be significant in the following situation:
  • One of the patches below is being applied.
    • 6.8.1 P17, P18, P19, or P20
    • 6.9.1 P04, P05, P06, or P07
  • The environment contains many workflows, or workflows with many sub-workflows.
Starting with 6.8.1 P21, and 6.9.1 P08, the patch includes a modification to a table that will significantly improve performance on this workflow migration, but it will still take additional time to apply.
The amount of time it takes to fix the workflow data will vary on the number of workflows (complexity), specifically how many sub-workflows are involved.
To determine the number of workflows involved, run the query below.
 
Select count(1)
              FROM wp_proc PROC
                JOIN wp_proc_cat proc_cat
                  ON proc_cat.PROC_ID  = proc.proc_id
                     AND proc_cat.PROC_DB = proc.proc_db
                JOIN wp_cat cat
                  ON cat.CAT_ID  = proc_cat.cat_id
                     AND cat.CAT_db = proc_cat.cat_db
                JOIN
                (SELECT proc.proc_id ,
                   proc.proc_db,
                   LENGTH(TRIM(TRANSLATE(proc.proc_ref, ' +-.0123456789',' '))) AS isNumeric
                 FROM wp_proc PROC
                ) numCheck
                  ON numCheck.proc_id     = proc.proc_id
                     AND numCheck.isNumeric IS NULL
              WHERE proc.proc_ref NOT LIKE 'acm$%'
                    --list of categories that we use....
                    AND cat.NAME IN ('Change Requests Custom',
                                     'Change Request Approval',
                                     'Change Request Activity',
                                     'Change Request Submission',
                                     'Change Requests',
                                     'Custom Task',
                                     'Escalation - Request',
                                     'Escalation - Review',
                                     'Escalation - ReviewSummary',
                                     'Escalation - Rule',
                                     'Rule Action',
                                     'Rule Exception',
                                     'Scheduled Tasks',
                                     'Collection Orchestration',
                                     'Rule Provisioning');

In 6.8.1 P21 and higher and 6.9.1 P08 and higher, let the patch application run, which is a one-time performance hit.  Once the migration has occurred it will not have to run again.
While applying the patch.sh script (or running the deployed ear), the patch will apply SQL. This is outputted to a file called Run-once.log.
(On jboss this is found here: ./jboss-4.2.2.GA/server/default/deploy/aveksa.ear/aveksa.war/log/run-once.log ).  
It is in the same directory as aveksaServer.log if the environment is a WAS/WLS system.
 
The following will be executing at the tail of the run-once.log file while the migration is running:
Start time [Tue Oct 27 10:39:31 EDT 2015]
DECLARE
  oldref                varchar2(16);
  newref                varchar2(16);
  in_proc_id numeric;
  in_prod_db VARCHAR2(18);
  v_dynsql VARCHAR2(32767);
  v_count       number;

BEGIN
    SELECT COUNT(*)
      INTO v_count
      FROM user_indexes
     WHERE index_name = 'WF_DATATYPE_VARNAME';

    IF v_count = 0 THEN
        EXECUTE IMMEDIATE
…..
….
) loop

    oldref      :=tbl.proc_ref;
    newref      :=tbl.new_proc_ref;
    in_proc_id :=tbl.proc_id;
    in_prod_db :=tbl.proc_db;

    v_dynsql := 'update wp_proc ud set proc_ref =:newProcRef where proc_id =:in_proc_id and proc_db =:in_proc_db';
    execute immediate v_dynsql using newref, in_proc_id, in_prod_db;

    ACCESS_REQUEST_PKG.UPDATE_PROC_REFS(oldref,newref);

  END LOOP;

This is the loop to look for.  This will help confirm if the migration is still running and if that is what is taking the time to apply the patch. 
NotesThis article applies ONLY the the versions below.
  • 6.8.1 P17, P18, P19, P20
  • 6.9.1 P04, P05, P06, P07
For further recommendations on making the patch application complete more quickly, contact RSA Support after running the SQL query above and submitting the results of that query in the case that is opened.

Attachments

    Outcomes