What is the best way for me to track which changes have been made to LifeCycles within OnBase Studio?

[Jessica_Moore_B]

Our organization uses a Development Environment, Testing Environment, and Production Environment set-up to ensure no one makes changes directly to the UI of the Production Environment Application without proper tracking.

We have been tracking the changes in a rather ham-fisted way. And we're hoping there's a better solution. So, what is the best way to compare the configuration within OnBase Studio for our Dev environment to that of our Test environment and our Production Environment?

Thank you in advance!

[Ramy_Mohareb]

Hi,

right click on the LC, copy , then paste in the same connection or different connection - test env may be (now you have a backup). 

Play and change to the copied one. Then right click > Compare To > "choose the original copy", then the system will show you the changes done side by side to the original.

Thanks

Ramy

[Jessica_Moore_B]

Hi Ramy.

Thank you for your response. That is basically what we're doing. But in order to prove to an Auditor that we have only made the changes that we said we would change, we have to do that for every Lifecycle, every time, even for the ones we are not changing. This also doesn't show changes made to the Workviews themselves.

I was hoping for something that might be a little more all encompassing and less time-consuming. Any thoughts?

Thanks!

[Ramy_Mohareb · Accepted solution]

OK. From my perspective i can see that you are already following the best practices following this method.

If you need more detailed and flexible way, i would suggest to have a select SQL query from all the tables that are updated when you modify any configuration in the life cycle, and save it before you start to do your changes, and run it again after you finish your changes, then you will have a tabular consolidated report for the auditor including the modified workview objects for all the lifecycles.

I don't have this query ready i apologize.

Thanks

Ramy

[Jessica_Moore_B]

I thought I would circle back on this and provide additional details about the change management process we have in place for our OnBase Application.

Our process is laborious and time-consuming. But it does allow us to meet the Federal Auditing requirements with great precision. Eventually, we hope to have all Lifecycles fully and properly documented within OnBase Studio in all three environments. Once that is in place, we should be able to generate an Administrators Guide and a Users Guide once a month and compare against the expected changes -- which should alleviate our need to do the one-by-one Lifecycle comparisons. But, for now, we use the below process.

GOAL 1) At any time, I must be able to quickly provide accurate documentation to a Federal Auditor about changes made to our OnBase Application in the past year with the approval of the Application Owners.

GOAL 2) At any time, I must be able to quickly provide accurate documentation to a Federal Auditor that proves no changes have been made to our OnBase Application within the past year without proper approval of the Application Owners.

GOAL 3) No person should ever be permitted to make a Lifecycle or Workview change directly to the Production environment of our OnBase Application.

GOAL 4) No changes shall be made to the Production environment of our OnBase Application without first being tested and approved by the Application Owners.

GENERAL ACTIONS

• Sync the databases and configurations of the Development and Test environments to those of the Production environment once a month.
• Record all requested changes and their requirements in a Change Management system of some sort
  • We use Jira.
• Make all requested changes within the Development environment.
  • Record changes made in corresponding task/story within Jira.
• Promote requested changes to the Test environment.
• Notify Subject Matter Experts to begin testing.
• Export from the Test Environment the updated Lifecycle, Workview, or Unity scripts.
• Archive a copy of the export file -- naming convention contains the date the file was exported.
• Archive a copy of the Import Results report. 
  • I don't remember what this is named right this second. But there is an option when importing to display a report of all imported items after the process is completed. We make a copy of that and archive it for posterity.

LIFECYCLE CHANGES

• Compare every Lifecycle in the Test environment to every Lifecycle in the Production environment.
• Archive the comparisons -- naming convention contains the date the file was exported.
• Investigate any difference that was not expected/requested.

WORKVIEW CHANGES

• Immediately before the Production promotion, obtain a row count of every table in the Test and Production databases.
• Run a pre-promotion comparison and archive the comparison results.
  • Compare the pre-promotion Production Row Counts to the prior post-promotion comparison.
    • Only data-entry specific tables should have a different row count.
    • If configuration-specific tables have a different row count, immediately investigate.
• Immediately after the Production promotion, obtain a row count of every table in the Test and Production databases.
• Run a post-promotion comparison and archive the comparison results.

SEPARATION OF DUTIES

In order to make fraud or other criminal activities more difficult for any one person to commit, we have a strict separation of duties.

• Development Team
  • Full access to Development and Test environments.
• IT Team System Administrator
  • Full access to Development and Test environments.
  • Read-only access to the Production environment.
• Application Owner System Administrator (Business SME)
  • Import/Export rights to the Production environment.
  • User and Usergroup configuration rights to the Production environment.
  • Document Type, Document Type Groups, and Keywords configuration rights to the Production environment.