RSA IG&L version 7.2 first impressions

[EdBertsch]

Hello friends,

Now that 7.2 has been released it will be nice to hear how things look with the product for those of us who download it, start to try it out in lower environments, and whoever will be the lucky one to deploy it on PRODUCTION.

Please share your experiences here. If you don't want to do that, please send me a PM or chase down my other contacts details. Google me, I'm easy to find.

Of course share your details with RSA too but since this is a user community, I hope that we can talk together without need for RSA to curate and shape the discussion, aside from their generous hosting of this forum itself.

I'm particularly interested in support for 18c/19c as a remote database for IGL, as just one of the big reasons I'm considering this release instead of moving to a higher patch level of the 7.1.1 than we're currently using.

[JamiePryer]

Thanks for starting this Ed.

What are you plans with this version? which key features are you interested in?

[MarcelvanKekere]

Jamie, Edward,

For me the main reasons to migrate are: stability, performance and solving issues.

[PradeepKadambar]

One intangible benefit that 7.2 offers is the redesigned workflow engine that stores much less data than the previous versions (up to 90% less data !!!).

This means that customers who are heavy users of workflows will see tepid growth in workflow table size.

[AndyCheek]

Pradeep Kadambar REALLY ????? Do you have any more quantifiable numbers that you would be willing to share? Certainly WP_USER_DATA has been the elephant in the room as far as our database is concerned so anything at all that will reduce the impact on that (and related) tables. Could be a key factor in pushing for the upgrade.

[PradeepKadambar]

Andy, as I mentioned it is up to 90% depending on the customers workflow implementation. I don't have statistics from the field but this feedback is more from internal testing.

I would like to make it very clear that it won't help with historical workflow data build up.

[JamiePryer]

Hey Andy,

we will have the ACME guide for v7.2x which I can share once available

[KevinPerkins]

I saw your first post and my hopes soared. Then, like Icarus, they crashed and died. You might want to edit your first post and add in that notice. It'll keep people's hopes at reasonable levels. Still very glad to hear it will slow growth.

[ShlomoKatz]

Please note: 

Chapter 8 (AFX install - pg 126) in the 7.2 Installation Guide, says:

      2. Run the AFX installation script:
         cd /tmp/aveksa/staging/deploy
            ./installAFX.sh -q

However, in my recent install, installAFXsh, is in /home/aveksa/staging/deploy/AFX-scripts

[AdarshKumar]

To clarify, while the new functionality in 7.2 vastly reduces the build up of data in the workflow tables, there are other options available in 7.1.1 (P02+), 7.1.0 (P07+) and 7.0.2 (P14+) that will help you manage the workflow table size. 

- Is the weekly out of the box data pruning being run? 

      - If Not, please start running that as it will purge a large majority of entries that are no more needed post workflow completion.

      - If Yes, is it completing in the 4 hours allocated for the run? 

            - If Not, please reach out to our support team and we can provide a script and instructions to run it more frequently to clean up your database.

            - If Yes but the database size is still large, please see the options below to determine if they apply to you. If they don't apply, you may need to upgrade to a latest patch of your 7.1.x version or to 7.2 as we started removing some additional rows that were not removed in the older patch versions.

- If the weekly pruning is being run, and the system is on a newer patch, is the record count high Or is the space consumption large?  There is a difference between the two, as the deletion of rows from Oracle tables does not release space back, the table keeps it.  A large table will keep the same space in the database after all of its records are deleted by a simple delete command until there is DBA activity to release that space.

- Are you ensuring that requests move to a final state in a timely manner.  For example, if some requests are a year old but not completed, that often points to a need to add some escalation workflow to move the request along or cancel it outright after some time. Any incomplete requests will not be archived and will stay around in the system forever. They also can create performance challenges for the system.

- Have you been Archiving old data? This way the data can be kept as a backup for Audit purposes, but all Archived data will be removed from the production system by the purge process.