SAP #BOBJ #BI 4.1 Upgrade Webcast Series 10: Promotion and Version Management

© 2014 SAP SE or an SAP affiliate company. All rights reserved. 1 Customer

SAP BusinessObjects BI 4.1 Upgrade

Webinar Series

BI 4.1 Promotion Management and

Version Management

Presenter: Matthew Shaw

Business Intelligence Architect, SAP

Twitter: @MattShaw_on_BI

Brought to you by the Customer Experience Group


SAP BusinessObjects BI Platform 4.1 Upgrade

Enablement

We bring to you all that you need to

successfully upgrade to the SAP

BusinessObjects BI Platform 4.1.

On SCN, you can find a BI 4.1 Upgrade

Overview and other resources at:

http://scn.sap.com/docs/DOC-56525

Webinars will complement these

published resources:









Agenda

High Level Architecture

– Separation of environments

– Dedicated System for Promotion Management

– Promotion Management Architecture

– Version Management Architecture

Promotion Management Best Practice

– Promoting Content

– Ad-hoc Content

– Deleting

– Connection Mapping

– Lots more tips and advice


Agenda








– Ad-hoc Content

– Deleting




Validate content

Test security

Test software (support packs,

patches etc.)

However, this presents a problem: How to manage moving content from

environment to environment.

Develop content (reports,

universes etc.)

Verify changes

Why is Lifecycle Management Important? Basic principal, separate environments


Why a dedicated system?

Promotion Management is really a ‘production’ system

It stores rollback content from a production environment which

could be critical if a rollback is required in your Production

system.

With the Version Management System it contains the versioning

and an audit trail of your BI content allowing that content to be

re-promoted or old content recovered. Could be critical to met

compliance regulations.

Avoids potential issues when promoting content the ‘Promotion

job owner’ does not have access to.

It’s really like any other production environment:

– Need to backup the system

– The ‘rollback’ content is stored as ‘instances’ in the output File Repository

Server

– The ‘versioning’ of content is stored in version management, so you must

also backup the version management database.

Promotion Management - High Level Architecture Why a dedicated system is recommended


Additional benefits of a dedicated Promotion

Management System

Allows for a refresh of ‘development’ and ‘test’ from

‘production’ without losing any Promotion Management

specific data.

Allows for ‘de-coupling’ of software releases between

Promotion Management and other environments.

– For example you can patch just Promotion Management

without affecting Production.

– Allows for Promotion Management Server to be

upgraded without necessarily upgrading Production. This

could be important, for example you may wish to

upgrade ‘Test’ before ‘Production’, but to be supported

you need to also upgrade the Promotion Management

Server

Promotion Management - High Level Architecture Why a dedicated system is recommended


Promotion Management - High Level Architecture

Why a dedicated system is recommended

Your ‘Promotion/Version Management’ server

must be the same major version as the source

and target systems. (i.e. all must be BI 4.x)

Differences of Minor Release and Service Packs

are supported as long as the server where the

Promotion Management Job is created and run is

on the ‘greatest’ version, in this example the

Promotion Management System:


Promotion Management - High Level Architecture Recommendation for a ‘non-connected’ system (airgap)


When a dedicate Promotion Management system is not

available, then host Promotion Management on

Production (probably 1st choice)

Or Test (probably 2nd choice)

Or Development (probably last choice)

With Production being ‘better’ than Test; and Test

‘better’ than Development purely from the standpoint

that Promotion Management should be considered

mission critical.

Do not operate Promotion Management from multiple

locations as this will be confusing and breaks proper

control process.

Promotion Management - High Level Architecture Other possibilities for a connected system


There are basically two workflows

Check-in. The creates a new revision of an object (like a document, or a universe)

every time you check it in.

Check-out. This overwrites the version in the Repository with the revision you select.

What is Version Management? Basic version management workflow


Only 1 Version Management

System ‘container’ can only be used

by 1 cluster (environment, ‘dev’,

‘prod’)

Each Version Management System

‘container’ has a set of ‘Working

Directories’

Version Management - High Level Architecture Version management system



Agenda








– Ad-hoc Content

– Deleting




A key basic principal for managing and

promoting content is to Test in Test, before

applying the very same content into

Production

Promotion Management Best Practices Basic promotion management workflow


If the test of that content was successful, we can

then re-run the same promotion job, but we

change the target to Production.

It is considered Best Practice to follow this

workflow.

This is the same workflow adopted by SAP

CTS+

Whilst we can easily change the target of a job,

and re-run, it introduces a problem.

Promotion Management Best Practices Basic promotion management workflow


Promotion Management – Best Practice Workflows

Key principals


It’s important we test the very same

workflows that are to be applied to

production in test.

Promoting content from Test to

Production does not follow this principal

and so it is considered poor practice.

The product is not designed for this

workflow. If you follow this practice you

will encounter issues.

Promotion Management Best Practices Considered poor practice


Option 1: Use a ‘LCM BIAR’ file to

materialise the content.

Promotion Management – Best Practice Workflows

Key principals – using LCM BIAR files


Option 2: Using VMS

Step 1: Create a job add it to Version

Management

– Optionally check-in multiple times. Each time

actually check-in all the content

Step 2: Check-out the job from Version

Management

– Doing so changes the source from ‘Development’

to ‘Version Management System’

Step 3: Promote the job from Version

Management to Test, then to Production

Promotions – Best Practice Workflows

Key principals – Using VMS


Demonstration


Using VMS to materialise content


Best Practice recommendations

–Create a folder called ‘Templates’ and create ‘template’

Promotion Jobs in it

oOnly edit these jobs, never run/export or check-in

these jobs

–Copy the ‘templates’ to a build folder and call it build

001, then build 002 etc.

oThese ‘builds’ are the ones you check-in/out or

export/import


Organise, use templates and builds


Managing Ad-hoc content oAh-hoc content in production

oContent becomes ‘mainstream’

oPromote back to Dev, then back

into Production


Managing ad-hoc content


Promoting a ‘deletion’ oMove the content to be deleted into a

‘Deleted items’ folder in Development.

oPromote the content into Production.

oAs long as no one has access to the

‘Deleted Items’ the objects is as good as

deleted.


Managing ad-hoc content


Mappings

Why use Mappings?

Just like all object types, create a connection

object once.

Just because the connection (in production)

contains different properties this is no reason

to create a new connection object (with new

CUID).

Tip! Don’t share connections across projects:

To prevent one connection mapping

interfering with another, define unique

connection properties (user, pass, server

etc.) for each Project on your BI Platform.


Xcelsius/Dashboards

Use a relative address to

– Avoids ‘cross domain’ errors

– Removes the need to change the .SWF file between environments.

Simply, use a relative address in the Web Service URL, and the .SWF will work in all environments.

All you need to move is the QaaWS objects themselves.

Mappings

Dashboard Web Service


Other Best Practices

Improving Performance

Removing the optional tasks will improve performance.

Removing the ‘rollback’ will improve the Job Promotion by 50%

Job Creation workflow is limited to web based timeouts (20 mins)



Job Creation – CMC or Command Line?

Primary use case (promote developed content):

– Use the CMC to create the Promotion Job and add objects, manage dependencies

– Keep the number of objects within any one job to less than 5000. (5 thousand)

o For product versions prior to BI4.1 SP2 this number is 100 (1 hundred) objects.

When promoting a larger number of objects:

– Use the LCM Command Line Interface

– Command Line will not suffer from any ‘web based’ timeout.

– Object selection is defined by a ‘query’ as there is no interface.

– So, it’s recommended to exclude ‘dependencies’ as this can result in a very large and unspecified number of

objects being accidently selected



Size and number of jobs

Don’t run too many jobs at once, this typically introduces confusion and

‘unknown’ rollback states.

Especially true when the same objects are being promoted in different jobs.

Consider setting the maximum number of concurrent jobs to 1 (default is 5)

Memory

When a job is run, all the objects are held within memory and thus

additional memory may be needed to prevent large jobs from failing.

Increase the memory on the Adaptive Processing Server hosting

“Promotion Management Service” by specifying –Xmx8g (for 8 GB of

RAM).

Guidelines

– Around 10,000 objects will need 8 GB

– Around 16,000 objects will need 16 GB



Organise

Organise promotion jobs in a folder structure that mimics production folder structure

Assign delegated administrators as desired

Use a consistent naming convention for promotion jobs

Do not promote

Do not promote security if it hasn’t changed

Security typically changes less often than content

Do not promote dependencies if they haven’t changed.

For example, universes change less often than reports

External Change Management ID

Use the ‘External Change Management ID’ to capture additional descriptions for that job so they can be

viewed in the audit trail.

The audit database captures promotion and version management events. This includes the ‘External Change

Management ID’ for the promotion event.


Test Promotion

You can test what would happen without affecting destination

Always test promote to identify conflicts

Test Promote will inform you:

Of new objects that will be added

Any name or CUID conflict

If there are missing dependent objects

What mappings will be applied (For BI4.0 FP3 onwards)

Test promotion does not check for rights of the user on the folders in destination.

When to set the schedule to run

Schedule promotion jobs, when load is at is minimum



Product support matrix

Objects support for Promotion & Version Management

Promotion Management Features

Dependency identification

Overrides/mappings support

Access the wiki at

http://wiki.sdn.sap.com/wiki/x/QofBEg

Promotion & Version

Management Support matrix




Agenda








– Ad-hoc Content

– Deleting




SAP BusinessObjects BI 4.1 Upgrade

Webinar Series

BI 4.1 Promotion Management and

Version Management

Q & A

Brought to you by the Customer Experience Group

Contact information:

Matthew Shaw

Business Intelligence Architect, SAP

Twitter: @MattShaw_on_BI

Appendix:

Delegated Administration


Delegated Administration Objective

Objective

‘Developer’ to create and edit Promotion jobs.

‘Developer’ to have NO access to Production, and NO update rights to Test.

‘LCM Controller’ to promote the jobs into Production, even though he/she has no access anywhere!


Delegated Administration Security setup

‘Developer’ has only view access in Test

and no update rights are granted in Test.

‘Developer’ can create new Promotion

jobs under ‘Development Jobs’, but

without a valid login that has update

rights for the target, the job will never run

and nothing can be promoted.



‘Administrator’ creates a new empty

‘Dev to Test’ job.

Within the job the login details for both

source and target are stored, but are not

visible!

‘Developer’ can:

– Copy this ‘empty ‘Dev to Test’ job’

– Create a new job from this existing

one, or just copy/paste the job to

duplicate it.

Just by access to this job, enables

access to the systems for those system

credentials stored within it.



Developer copies the ‘empty Dev to Test’ job into his project folder and adds objects to it.

Developer can not see the usernames/passwords set. However this does not stop Developer from editing or

running jobs which can make changes, such as additions or edits, to the target, even though Developer does

not have create or edit rights on the target!

Developer can setup a schedule to run his job on a regular basis to promote content from Development to

Test.



Developer checks Test environment and is satisfied that the job definition and the

content of the source ‘Development’ environment is correct.

Developer moves his/her job(s) into the folder ‘Test Complete’.

LCM Controller is informed that a new promotion into Production is ready and

required.



LCM Controller can not do anything with the jobs held in ‘Test Complete’ folder except to move them to another

folder.

LCM Controller moves the job from ‘Test Complete’ to ‘Accepted Jobs’

LCM Controller is denied the application rights ‘Edit jobs’, ‘Edit LCMBIAR’, ‘Allow access to Manage

Dependencies’, so preventing any objects being added/removed from the job.

LCM Controller is denied the application right ‘Create Job’, so ensuring all jobs follow the standard process and

no ‘ad-hoc’ jobs are created.



‘Edit’ and ‘Schedule’ rights are required to test promote and to promote a job.

LCM Controller will need to edit the job to specify the target and, if using XI3, any connection mappings.

‘Edit’ and ‘Delete instances’ are granted so LCM Controller can edit and delete all instances, not just the ones he

owns as ‘Edit objects that the user owns’ and ‘Delete instances that the user owns’ is inherited from the

‘Schedule’ role. ‘Edit’ and ‘Delete instances’ is required for rollback.



LCM Controller changes the ‘target’ of the job from ‘Test’ to ‘Production’.

Access to ‘Production’ is specified:

– The LCM Controller enters the username/password for the user that will perform the promotion into Production.

This user will need edit rights on the target, usually an administrator.

– OR, if using XI3, just opens an existing job that already has the ‘Production’ login credentials specified. Just like

we’ve done for the ‘empty Dev to Test’ job, however we’re just opening the job, not editing it, so to gain access

to the production system.



LCM Controller runs the job and promotes content from Dev to Production.



Developer can only view the jobs in ‘Accepted Jobs’, so once the job has run, Developer can inspect the job for

success or failure and see the details behind any failures. Developer and/or other users can also query the audit

database for a detailed audit trail.

Only LCM Controller can perform a rollback against Production


Combine this workflow with:

• The ‘template’ and ‘build’ concept

• Materialising the job:

• BI4: The ‘check-in’ and ‘check-out’ with Version Management

• Check-out the job before moving the job to the ‘Test Complete’ folder

• Or, XI3 & BI4: within an LCMBIAR file

Delegated Administration

Technology

SAP #BOBJ #BI 4.1 Upgrade Webcast Series 10: Promotion and Version Management