Skip navigation

RSA IGL Version: V7.1x & V7.2x

Modules: Governance

Product Area: Reviews

Note: A summary of all RSA IGL recipes can be found here: (TBC)

Time to apply: ~30 minutes



This recipe combines web services and workflows to automate and control the review change request generation tasks. The recipe combines the benefits of both out of the box Automatic and Explicit review change request generation options with minimal configuration.




The RSA IGL Reviews module provides 2 methods for generating change requests, as explained below:


1. Automatically

Since change requests are automatically created as soon as reviewers saves their decisions, you get the following:


  • No additional administration overhead for the review owner or administrators to periodically generate change requests.


  • There is no control over the timing of the generated change requests.
  • There is no control over the grouping of change items.
  • Reviewers have no margin for error since a change request is generated the moment they save their changes.


2. Explicitly by Owner

Since change requests are not generated until the review owner or administrator manually triggers the change request generation, you get the following:


  • More control over the change request generation grouping (By Reviewer, By Component ... etc).
  • More control over the time when change requests are generated (Daily, Weekly ... etc).
  • Reviewers have the ability to review and change their decisions until the next change request generation task is run.


  • Additional overhead of the review owner or administrators to manually start the change request generation process.
  • Potential of missing a few changes if the review owner or administrator does not manually generate the change requests. 




One of the most common requests we've seen is a solution that combines the benefits of both Automatic and Explicit change request generation. The requirements are mostly:

  1. Having the ability to control the timing and grouping of generated change requests without requiring manual intervention from the review owner or administrators.
  2. Giving reviewers a grace period - for example: until the end of the business day or end of the week - to change any decisions they took before any change requests are generated without requiring the review owner or administrators to perform manual actions outside business hours.


Suggested Solution 


We can leverage the createRequestsByOwner web service command which is used to generate change requests for a review. This is equivalent to the 'Create Change Requests' button found on the Change Preview tab of reviews that are configured to generate requests explicitly by owner.


Web Service Usage

Note: The below is only the relevant subset of the full web service description. For full usage details, you can go to Admin > Web Services > Requests > Click 'Click for details' beside the createRequestsByOwner web service.


Input Parameters

The command expects the following parameters where a * denotes a required parameter:

  • id* - The id of the review result to create change requests for.
  • group - Specifies how changes should be grouped together.
    • Reviewer, PerComponent, PerAsset valid for user reviews.
    • Reviewer, PerComponentResource, PerComponent, PerAsset valid for account reviews.
    • PerComponent valid for group and role reviews.
  • format: The format to return the data in (default = properties)


Output Parameters

The command returns the following properties as output:

  • name - name of the review.
  • status - success or failure.
  • message- Optional message to return along with the status.

A precondition failed (412) return code is returned if the review is not configured to generate requests explicitly by owner.



An example url used to invoke this command is shown below:



Calling the Web Service


There are two suggestions on how to call and schedule this web service:


Option 1 - Review Escalation Workflows

Using a Review Escalation workflow which calls createRequestsByOwner for the specific in scope.

  • Simple to implement and has better visibility on runs per review.
  • Also easier to have different options/frequency per review.


  • Review Escalation workflows cannot be triggered in a recurring way (every day). So an escalation must be added per exection. Depending on the duration of the review, this could require a large number of escalation workflows.


Option 2 - Custom Task Workflows

Schedule a generic Custom Task workflow that calls the createRequestsByOwner for all open reviews.

  • A single workflow should work for all active reviews.
  • Better scheduling frequency options.


  • Less visibility on runs per review.
  • Extra complexity to control options/frequency per review type.




Web Service Security Settings

Make sure you thoroughly test any changes in lower environments first before promoting them to Production.

Make sure you are on 7.1.1 P07 / 7.2.0 P01 or above to be able to call the web service from workflows without a token (Reference ACM-103573).


You need to make sure of two things:

  1. Enable Web Services and whitelist the IGL server(s)' internal IP addresses.

  2. Enable the "Request Forms and Workflows (no token)" checkbox for the createRequestsByOwner web service.


Workflow Configuration


Option 1 - Review Escalation Workflow


  1. Create a new "per Review" Review Escalation Workflow

  2. Configure a simple REST node that calls the createRequestsByOwner web service.

    URL: https://<Internal-Hostname>:<Internal-HTTPS-Port>/aveksa/command.submit
    Method: GET
    Request Params:
    cmd: createRequestsByOwner

    format: properties
    group: <Grouping option of choice>
    id: ${jobUserData_acm.ReviewId}

    Content-Type: text/plain

    Proceed on failure: Checked
    Response Type: Properties
    Response Variables:
    status: Job, status

  3. Add the escalation workflow to the Escalations tab of the review definition as much as required.
    Example running this workflow on a weekly basis for 4 weeks (28 days):


Useful Tip for Scheduling Review Escalation Workflows


Since Review Escalation Workflows do not have the ability to specify the exact time (hours and minutes) the workflow will run on a specific day, you can use a Delay node with SQL Delay that returns the today's date at a specific time.


For example, if you want the change request generation to be triggered at 9:00 pm. Then it can be calculated as follows: 

  • trunc(sysdate) returns today's date at exactly 12:00 AM (00:00)
  • + (day fraction) to add the exact time offset required. For example, 9:00 PM is 21:00 which means 21 / 24.
    trunc(sysdate) + 21 / 24 AS wait_date


Option 2 - Custom Task Workflow


  1. Create a Custom Task workflow.

  2. Add a SQL Select node that gets any non-completed Review ID that is configured to generate change requests explicitly by owner. Use the following SQL statement as an example:
    SELECT    AS review_ids,
        0        AS tmp_id
             t_av_entreviewdefversions rdv
        JOIN pv_review rv ON rv.review_definition_id =
                             AND rdv.generate_change_request = 'M'
                             AND rv.state IN (


  3. Configure a Next Valye node to loop through the Review IDs

  4. Add a REST node with the same configuration as in Option 1 Step 2. The only difference is that the Review ID is now in the created Workflow Variable ${jobUserData_TMP_ID}

  5. Make sure the two transitions coming out of the Next Value node are set to Completion Code.
    • True: Continue looping.

    • False: Finish process.

  6. Schedule the Custom Task workflow as required.


This may or may not work on RSA IGL v7.2 depending on the installation options. For example, in 7.2 we allow installing the application under a different folder than the previously standard /home/oracle.

So I wouldn't recommend using it on 7.2 yet.

Full backups are a crucial measure for RSA Identity Governance & Lifecycle or generally any other enterprise application. Your organization probably has a strict backup policy which would mention aspects such as:

  • Backup frequency
  • Backup contents
  • Backup storage location
  • Backup retention


On the other hand, scheduling full backups for RSA Identity Governance & Lifecycle following our best practices could be challenging. You would need to take into consideration:

  • Backing up all important components (Database, Encryption Keys, Keystores?)
  • On highly active environments, it is recommended to schedule the database backup while the application is down to ensure a consistent backup.
  • Removing old backup files so as not to fill up the file system.
  • Notifying the system administrator of any backup failure.


RSA Professional Services created the attached bash script as an example of backup using our best practices and as a base for any further modifications required to meet your organization's backup policies. The script is split into separate functions to allow easily building extra functionalities on top of the existing ones. Currently the script will:

  1. Stop the Application (and AFX if exists).
  2. Perform a database backup.
  3. Start the Application (and AFX if exists).
  4. Compress the database backup + the database encryption keys + the application server keystores into a full backup file.
  5. Remove both database and full backup files older than a preset threshold.
  6. Perform checks on the database backup status and possibly notify the system administrator upon any failures.
  7. Possibly copy the full backup files to remote share.




The script must be run as oracle and is cronjob friendly. The usage is very simple, just make sure it has the correct execute permissions for the oracle user then run it as follows:

> ./


By default the script creates the full backup files under /home/oracle/fullbackups and is configured to keep only the last 3 backup files. You can easily overwrite either of those value by setting the environment variables FULLBACKUP_DIR and OLD_BACKUPS_TOKEEP first. For example, using the following syntax:

> env OLD_BACKUPS_TOKEEP=10 FULLBACKUP_DIR=/home/oracle/my_full_backup_dir ./


Restore Procedure


  1. Create a temporary restore directory anywhere. For example:
> mkdir /home/oracle/fullbackups_restore


  1. Extract the compressed file in that directory. For example:


> cd /home/oracle/fullbackups_restore
> tar -xvf /home/oracle/fullbackups/DailyBackup_20190602_120243.tar.gz


  1. List all files to make sure they were extracted correctly. Ideally there should be three file extensions:
    1. *.dmp -> Database backups.
    2. *.key -> Encryption keys.
    3. *.keystore -> Keystore files.


For example:


> cd /home/oracle/fullbackups_restore
> ls -l
   total 1059580
   -rw-r----- 1 oracle oinstall 1084977152 Jun  2  2019 Export_AVDB_avuser_DailyBackup_20190602_120243.dmp
   -rw------- 1 oracle oinstall         26 Mar 18  2019 9K9.key
   -rw------- 1 oracle oinstall         26 Mar 18  2019 Xmk.key
   -rw-r--r-- 1 oracle oinstall       4815 Apr  2  2018 aveksa.keystore
   -rw-r--r-- 1 oracle oinstall       5301 Mar 18  2019 server.keystore


  1. Stop AFX if exists, then the application. For example:


> afx stop
> acm stop


  1. Copy the database backup file to the default Export/Import directory, then restore the database backup.
    The backup file names are in the format Export_<DatabaseID>_<DatabaseUser><Tag>.dmp. You need use the -t <Tag> option to specify the backup file you want to import.

    For example, the tag value from Export_AVDB_avuser_DailyBackup_20190602_120243.dmp is _DailyBackup_20190602_120243 (including the leading _) as shown below:


> cp /home/oracle/fullbackups_restore/Export_AVDB_avuser_DailyBackup_20190602_120243.dmp /home/oracle/AveksaExportImportDir
> avdbimport -t _DailyBackup_20190602_120243


  1. Copy the .key files to the security directory and update their permissions to the expected value (rw- --- ---). For example:


> cp /home/oracle/fullbackups_restore/*.key /home/oracle/security
> chmod 600 /home/oracle/security/*


  1. Copy the .keystore files to the keystore directory. For example:
> cp /home/oracle/fullbackups_restore/*.keystore /home/oracle/keystore


  1. Start the application, then AFX if exists. For example:
> acm start
> afx start


  1. Once you confirm everything is fine, you can delete the temporary restore directory. For example:
> rm -rf /home/oracle/fullbackups_restore


We would really love to hear your feedback and you can always contact RSA Professional Services through your account manager if you are interested in adding more customizations to the backup script.