From DEV to QA to PROD using LifeCycle Manager

LifeCycle Manager (LCM) is a plugin for BusinessObjects Enterprise XI 3.1 that allows content promotion and version management. In this article you will find guidelines to help you decide where to install life cycle manager, when is a good idea to use rollback and main steps required to use LCM to promote (transport) content from one BOE system to another.

Where to install LifeCycle Manager?

Installing in DEV, QA, PROD or in additional standalone server?

When using LCM for content promotion, you create jobs. Each job contains infoobjects that can be moved from one BusinessObjects Enterprise deployment to another BusinessObjectsEnterprise deployment. Jobs are infoobjects itself and are stored in the CMS repository and in the Input FRS. Once a job is created it can be used several times to promote content from one deployment to another. Something to consider when deciding where to install LifeCycle Manager is that you probably want LCM jobs in a deployment where you have a backup strategy.

LCM is a server installation and requires the following servers to be available when you are installing:

• Central Management Server: This is required so the infoobjects related to LCM can be created.
• Adaptive Processing Server: LCM installation adds the LCM Job Server, the Adaptive processing server is required for the creation of the LCM Job Server.
• Web Application Server: LCM is a web application
• Input FRS : This is a server you need available after installing, as jobs that you create in LCM are saved in the Input FRS and CMS repository.

LCM SP2 is only available as a full install for Unix. Unix installs allows you to perform a distributed install. For Windows full install is only available for the first version of LCM, in this first version distributed install is not implemented. This means that in Windows you need all the above servers to be on the same machine. You could manually deploy LCM in a distributed DEV, QA or PROD deployment, or you could add a third server which just has the above servers plus FRS (as jobs are stored in the FRS) and use this server only for content promotion from your deployments. Having a third server for LCM is possible as long as your deployments are not isolated as LCM has to be able to connect to source and destination deployments to promote content.

Where to install in a clustered deployment?

If you have a clustered deployment, you could have a standalone server just for LCM (CMS+Adaptive Processing Server+Web App+LCM) or you could install LCM in one of servers in the cluster. If this is a Windows distributed install (i.e. Web Application Server and CMS are on different machines) you will need to do a manual install of LCM.

Where to install if deployments are isolated?

If your DEV, QA and PROD deployments are isolated, you will have to install LCM on all your deployments and use the LCMBIAR export/import functionality to move content from one deployment to another.

How to transport content from one BOE environment to another?

Specifying content to promote

To transport or promote content, you first have to specify which content you want to promote. This is done in LCM tool with 3 main steps:

1. Create a Job
   • A Job is a collection of infoobjects that can be moved from one Business Objects Enterprise deployment to another Business Objects Enterprise deployment.
   • Before creating jobs, consider creating folders to organize them.
   • In LCM you can create folders by clicking on the New Folder icon.
   • To create a new Job you click on the New Job button.
   • When you create a new job you must logon to the source system and an Input FRS should be running and enabled as the Job is saved as an InfoObject in the CMS database and as a file in the Input FRS. You don't necessary have to logon to the destination system at this time.
2. Add infoobjects to the Job
   • When you create a job is empty, you have to add infoobjects by clicking on the Add Objects button.
   • It is best practice that you select a small number of infoobjects for a Job. For promotion to obtain optimum performance you should not exceed of a 100 objects at a time.
3. Verify Dependencies
   • Primary resources that you added to the job may depend on other objects to perform its activities. All objects that the primary resource depends on are dependent objects. For example a report is dependent on a universe, a universe is dependent on a connection.
   • Dependent objects are computed by LCM only when you click on Manage Dependencies.
     

Job Promotion

You can promote content when deployments are connected and also when they are isolated. When deployments are isolated you use a LCMBIAR file to transport the content. Before actually promoting a job you can set different options, depending if the deployments are connected or not this is done on the source or destination.

• Map connections
  You can map a connection or edit the database information of the connection.
  Use mappings to override:

• • Connection mappings
    A connection can be mapped to the appropriate connection in the destination environment. You can override Universe connections, Voyager connections and Business Views connections. If the connection does not exist in the destination environment, you can use the option Edit Connection Properties, to specify the connection information that should set in the connection when the connection is in the destination environment.

    For SAP BW universe connections, Edit Connection Properties can't be used for now, as this option currently does not allow to specify all the connection information that is needed for a SAP BW connection.

In SP2 it is now possible to override Universe connections in bulk.

• • Crystal Reports database info
    Database information in a Crystal Reports can be updated. In SP2 you can modify the database information for all reports connecting to the same database.
    

• • Query as a Web Service URL
    The URL for the WSDL can be updated. In SP2 this can be done in bulk.
    

• • Federation mapping
    In SP2 you can modify federation connection properties
    

• Security
  You can specify to promote the security of the objects in the job as a best practice only promote security when changes have been made, typically with a significant revision of the application.

When configuring security you have the following options:

• • Include Security: This option promotes the security of the objects that exist in the job like reports and its dependencies, folders, users and user groups.
  • Application Rights :This is an optional selection, if selected it additionally also promotes the application rights of all the applications that the user and user groups present in the job have access to.

• Test Promotion
  You can Test what would happen when promoting the job, without committing the objects to destination
  
  Test promotion does not check for rights of the user on the folders in the destination system. Objects that were successful in the "test promotion" could still fail to actually promote due to security reasons.

• Schedule Job
  To promote a job you can schedule it, so job promotion happens at fixed interval, when the load on the deployment is at is minimum.
  

Job Promotion Best Practices

• Organize promotion jobs in folder structure that mimics production folder structure
• Use a consistent naming convention for promotion jobs.
• Assign delegated administrators as desired.
• For promotion to obtain optimum performance you should not exceed of a 100 objects at a time.
• Do not promote security if it hasn't changed; security typically changes less often that content.
• Do not promote dependencies if they haven't changed. For example universes will change less often than reports, so only promote universes when they have changed.

When to use rollback?

Rollback allows you to restore the destination system to its previous state, after a job has been promoted. When an issue is identified with the deployed content you can fix the issue in DEV environment and promote the fix using LCM or roll back some or all of the deployed content to a previous state.

Rollback can be used when:

• Issue is in production
• Change must be reversed quickly
• Scope of changes to be rolled back is large

Roll back Best Practices

• Enable rollback only on for critical systems, as rollback consumes disk space.
• Only roll back when abosolutely necesary and avoid rolling back more than one version.
• If you need to rollback security changes do a full rollback not a partial rollback.

Rights for LifeCycle Manager features

Access to LifeCycle Manager features is configured by rights on LCM Folder and on LCM application.

Logon to LCM

• LCM Folder Rights:
  
• LCM Application rights:
  No right is needed in LCM application.

Create, edit, copy and paste Jobs

• LCM Folder Rights:
  
• LCM Application rights:
  

.

Delete Jobs

• LCM Folder Rights:
  
• LCM Application rights:
  

Rollback Jobs

• LCM Folder Rights:
  
• LCM Application rights:
  

Promote Jobs

• LCM Folder Rights:
  
• LCM Application rights:
  

References and links