...

Proven Practice Go To Production in IBM Cognos Contributor

by user

on
Category: Documents
1

views

Report

Comments

Transcript

Proven Practice Go To Production in IBM Cognos Contributor
Proven Practice
Go To Production in IBM Cognos
Contributor
Product: IBM Cognos Contributor
Area of Interest: Performance
Go to Production in IBM Cognos Contributor
2
Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC
is an IBM Company. While every attempt has been made to ensure that the
information in this document is accurate and complete, some typographical
errors or technical inaccuracies may exist. Cognos does not accept
responsibility for any kind of loss resulting from the use of information
contained in this document. This document shows the publication date. The
information contained in this document is subject to change without notice.
Any improvements or changes to the information contained in this document
will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this
document may be copied, photocopied, reproduced, stored in a retrieval
system, transmitted in any form or by any means, or translated into another
language without the prior written consent of Cognos. Cognos and the
Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)
in the United States and/or other countries. IBM and the IBM logo are
trademarks of International Business Machines Corporation in the United
States, or other countries, or both. All other names are trademarks or
registered trademarks of their respective companies. Information about
Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology
team. You can send comments, suggestions, and additions to
[email protected] .
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
3
Contents
1
INTRODUCTION ............................................................................................ 4
2
THE PRODUCTION APPLICATION ................................................................. 4
2.1
2.2
MODEL DEFINITIONS AND DATA BLOCKS .................................................................4
CUT-DOWN MODELS AND MULTIPLE LANGUAGES ..............................................................5
3
THE DEVELOPMENT APPLICATION ............................................................... 6
3.1
3.2
DEVELOPMENT MODEL DEFINITION .............................................................................6
IMPORT DATA BLOCKS .............................................................................................6
4
ADMINISTRATION INTERACTIONS WITH THE PRODUCTION APPLICATION7
4.1
HOW CHANGES ARE IMPLEMENTED ..............................................................................8
5
GTP STAGES .................................................................................................. 9
5.1
5.2
5.3
5.4
5.5
5.6
5.7
GTP WIZARD – OPTIONS STEP ..................................................................................9
GTP WIZARD – SHOW CHANGES STEP .........................................................................9
INVALID OWNERS AND EDITORS AND E.LIST ITEMS TO BE RECONCILED:................................ 10
GTP WIZARD – GTP ........................................................................................... 10
WARNINGS........................................................................................................ 14
CLIENT-SIDE-RECONCILIATION ................................................................................ 14
E.LIST ITEMS NOT REQUIRING RECONCILIATION............................................................ 15
6
BACKUP PROCESSES ................................................................................... 15
6.1
6.2
MID-GTP FAILURES ............................................................................................. 16
RECONCILIATION FAILURES .................................................................................... 16
7
ANALYST ..................................................................................................... 18
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
4
1 Introduction
This article will describe the stages and steps required in the Go to Production (GTP)
process for IBM Cognos Contributor. The most significant feature of GTP for end
users is that it provides Web client users with 24/7 access to an application, while
allowing application administrators to make any changes they like to the application.
Also, it is an important factor in helping us to ensure that Contributor applications
are made as robust as possible. Fundamentally this is because GTP acts as the sole
point of contact between the development application and the production
application. A lot of effort has gone in to keeping this point of contact as limited as
possible.
GTP allows an administrator to formally commit a set of changes. All these changes
must pass through GTP, so this provides an opportunity to interrogate the state of
the development application, and intercept as many problems as can be predicted.
GTP can be automated and scheduled, so you can schedule it to run in a period of
minimal application use. If the GTP (or subsequent reconciliation) processes were to
fail, it is a simple matter to roll back the application to its previous state. In this way,
GTP can act as an invaluable checkpoint or snapshot of an application.
Finally, GTP is an essential part of the overall planning process. Most planning
activities are essentially cyclical, but in order to have some control over such
processes, some stability is required within stages of the cycle. GTP provides a
mechanism to formally move between cycles or stages of a cycle – you can
implement a batch of changes, including new assumptions and import data, allowing
you to create checkpoints or versions of an application. This is particularly important
when there is collaboration or interaction between different planning activities.
Different users working on a plan need to work with a consistent set of assumptions
and model logic – they need a single version of the truth.
When there is interaction between multiple Contributor applications, the
interdependencies between them must be managed carefully; some consistency of
assumptions, for example, will be required. A publish from one application (which
always ensures a consistent read of the data) can be partnered by an import and
GTP in another.
2 The production application
The production version of a Contributor application fundamentally consists of one or
more “model definitions”, and one “data block” for each contribution or review e.List
item.
2.1 Model definitions and data blocks
A model definition is a (virtually) self-contained definition of the model. It holds
definitions of the dimensions, cubes, and D-Links of the model, as set up in Analyst.
It also holds details of modifications applied in the Contributor Administration
Console:
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
5
•
Configuration details such as navigation order for cubes, options such as
whether reviewer edit or slice and dice are allowed, Planning Instructions and
Planning Headlines, and so on.
•
E.List details.
•
Access table definitions.
The model definition also contains all assumptions cube data, since this does not
vary by e.List item.
The data block for an e.List item contains all data relevant to an individual e.List item
(except assumptions cube data). It contains one element of data for every cell in the
model, except for any cell identified as “No Data” by Contributor access tables. No
Data cells are generally treated as if they did not exist, reducing the volume of data
which needs to be downloaded to and uploaded from clients, speeding up client-side
recalculation and server-side aggregation.
When a Web client user opens a contribution – by clicking an e.List item name in the
status table – a model definition is opened, then the appropriate data block is loaded
into it. If a multi e.List item view is opened, more than one data block is loaded.
Wherever possible, the model definition and data block will be loaded from the
client-side cache (if enabled). If the client-side cache does not contain an up-to-date
version of the model definition and/or the data block, one or both will be
downloaded from the server. Note that data in the data block is not compressed,
although compression and de-compression does take place on transmission to and
from the client.
For example, in addition to a data block, each e.List item can also have an
“annotation block” (if annotations are enabled), and various translation tables will
exist if multiple languages are being used. However these extra elements are not
fundamental and have no material impact on the behavior of GTP.
2.2
Cut-down models and multiple languages
If neither cut-down models nor multiple languages are used, there will be just one
“master” model definition for an application.
When cut-down models are used, separate model definitions are produced for
individual e.List items or groups of e.List items, according to the cut-down model
option chosen. A cut-down model definition contains only the relevant portion of the
e.List, and just the required dimension members – D-List items whose cells are all
defined as No Data are removed. If cut-down models are enabled, Web client users
will use a cut-down model rather than the master model definition. Cut-down model
definitions can be significantly smaller than the master model definition, thus
speeding model download time for the client.
Cut-down models also speed up model opening time for the client, as the master
model definition holds rule-based access table definitions that must be “resolved” (to
actual per-cell access levels) when it is opened, whereas access levels have already
been resolved in cut-down model definitions.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
6
When multiple languages are used, a separate master model definition exists for
each language in use by the application. Each master model definition contains just
the relevant translated strings. The principal reason for this is to stop the master
model definition becoming excessively large.
An application can use multiple languages and cut-down models. In Contributor
versions prior to 7.2, this required a separate cut-down model definition for each
relevant language. In Contributor 7.2, language-specific cut-down models are no
longer produced, due to the introduction of security integrated with Access Manager
(which means that we don’t know which languages will be required for an e.List item
until run-time).
Note that data blocks only ever hold valid data for a single e.List item, so they are
always “cut-down”.
3 The development application
Web client users only interact with the production version of an application (as
summarized above). All application configuration or administration is performed in
the development version of an application, and this has no impact on the production
application or the Web client users, until the administrator chooses to GTP.
In considering GTP, only two components of the development application are really
relevant: the development version of the master model definition, and a set of
“import data blocks”.
3.1
Development model definition
With the exception of data import, any configuration performed in the development
application will affect the development model definition. In the Contributor
Administration Console, changes are implemented to the development model
definition as soon as they are saved. For example, new access table definitions are
stored in the development model definition when you click the Save button in the
main Access Tables screen.
Currently most development configuration changes can only be made through the
Contributor Administration Console.
Note: undo is not provided for individual changes made to the development
application, but you can reset the entire development application (which will then
match the current production application), using the Contributor Administration
Console Reset Development to Production tool bar button.
3.2
Import data blocks
The final stage of the Contributor import process creates a set of import data blocks.
This “Prepare” stage extracts data from the import staging tables and creates one
import data block for each contribution e.List item with import data. Import data
blocks contain data for one e.List item only, and contain only valid data. Invalid data
such as data that does not match any dimension item or targets formula items or No
Data cells, is written to an import errors table (ie_cubename). No import data block
is created for e.List items with no import data.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
7
By removing all irrelevant or invalid data, the import data block for an e.List item is
kept as small as possible. This is crucial for the subsequent reconciliation process,
particularly for client-side reconciliation.
In the Contributor Administration Console, you can see the results of the Prepare
process in the Prepared Data Blocks tab of the Import Data screen. Here, those
e.List items with import data blocks are listed, and the number of target data cells
per cube is given.
Note that if you use the Prepare “zero data” option, an empty import data block is
created for all e.List items.
The prepare process is performed using the job architecture (a Prepare_Import job),
so can be scaled out, monitored, and so on in the normal way. It will not conflict
with other jobs for the application, but it will not be possible for the application to
GTP until it is complete.
The import process, including the Prepare stage, can be controlled from the
Contributor Administration Console or through Contributor Automation components.
The end result of an Analyst to Contributor D-Link is also to create a set of import
data blocks. These are identical to those produced by the import process.
4 Administration interactions with the production
application
Generally, there is no direct interaction between application administration and the
production application. However, there are some minor exceptions:
•
Publish extracts data from the production application (there is no user data in
the development application). Only the first publish process (Prepare_Publish)
actually interacts with the user data. This is a simple operation and takes little
time, so interaction with the Web client users is minimal.
•
User and audit annotations can be deleted from the production application.
This option provides an administrator to manage the volume of annotation
data. It is recommended that this be done when no Web client users are
editing, primarily because any annotations held in a model opened by a Web
client user will not be deleted.
•
Extensions are configured in the production application, and there is no need
to GTP after making changes. This is essentially because extensions do not
modify the core application (i.e. they do not affect model definitions or data
blocks); they are designed to safely extend and customize an application.
•
The production preview allows an administrator to view the last saved data
for any e.List item. Although this allows the administrator to modify data (i.e.
to test the operation of the model), the administrator cannot save changes,
so there is no impact on the Web client users.
•
If you are using integrated security in Contributor 7.2, you can alter user
assignment to user class in Access Manager, thereby indirectly altering the
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
8
assignment of users to e.List items in Contributor, without having to GTP to
implement these changes in Contributor.
4.1
How changes are implemented
Apart from the exceptions mentioned above, all changes are made in the
development application and do not affect the production application until they are
implemented by GTP.
GTP consists of various processes – a pre-production process, the GTP process, and
a post-production process – which are described in detail below. The crucial stage is
the GTP process itself. This is where the old production application is replaced by the
incoming development application.
Note: Remember that the GTP process is the key stage within GTP.
Until the GTP process itself, all Web client users can use the old production
application as normal. Immediately after the GTP process, there is a new production
application, and basically this is what all Web client users will now use. For example,
after the GTP process, Web client users attempting to open a model will only have
access to the new production application. However, there are complications
associated with the fact that users might already be viewing or editing a model from
the old production application at the time of GTP – “client-side reconciliation” will be
required.
In the GTP process the old production model definition is replaced by a new
production model definition (the incoming development model definition). Many
development changes will have no affect on the structure or content of production
data blocks and will affect the production model definitions only – for example,
everything appearing within the Configuration branch in the Contributor
Administration Console. If these are the only changes made, then the production
application will be fully updated when GTP is complete.
Other development changes will require a new production model definition and
require the production data blocks to be updated. For example, a synchronize with
the Analyst model can change the structure and content of data blocks in very many
ways. If changes that affect data blocks have been made, the GTP process will fully
update the production model definitions as normal, but the data blocks will be
updated by a subsequent “reconciliation” process (handled by a Reconcile job).
If an import has been performed in the development application (or if Analyst to
Contributor D-Links have been run), then import data blocks will have been created.
If there are import data blocks at the point of GTP, then the GTP process will “move”
these import data blocks into the new production application. After GTP, the import
data blocks will be combined with the production data blocks, which are also handled
by the reconciliation process. Note that after GTP, the import data blocks will have
been removed from the development application – this is the one case where GTP
has an observable effect on the development application.
In summary: GTP replaces the old production model definition with a new one, and
moves any import data blocks into production. If there are import data blocks or
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
9
changes that affect production data blocks have been made, then the production
data blocks will be updated by a reconciliation process which follows on from GTP.
5 GTP stages
The GTP wizard is described briefly as it is well documented in the Contributor
Administration Help. The GTP processes apply equally if GTP is triggered using
Contributor Automation (AutomatedGotoProduction.xml script).
You will not be able to GTP if there are incomplete jobs for the application. This
includes jobs not resulting from GTP such as Publish and Prepare_Import, as well as
jobs invoked by GTP such as Cut_Down_Tidy. Note that this also includes the
Reconcile job – only one reconciliation at a time is possible for an application.
Reconciliation can take a significant amount of time, so if reconciliation is required, it
is worth checking that you have made all required changes before you GTP.
5.1
GTP wizard – Options step
Here you choose various options:
•
Creates a backup of the entire Contributor application, including all data in
the production application. It is highly recommended. Note: the GTP
automation component does not have a backup option – it is assumed that a
script will request a backup prior to running the GTP automation component.
•
Reset workflow states: You can choose to leave workflow states in the
production application as they are, or reset them in various ways.
•
Display invalid owners and editors: If you check this option, invalid owners
and editors will be displayed in the next screen.
Note: two other options are found in the GTP Options tab in the development
Application Settings screen, which influence the behavior of GTP:
•
Copy Development e.List item Publish Setting to Production Application.
•
Prevent Client-side Reconciliation.
5.2
GTP wizard – Show Changes step
Once you proceed beyond this screen, you are committed to proceed with GTP. This
is your last chance to cancel, so it’s worth checking the information in this screen
carefully.
Show changes tab:
•
This screen makes available a summary of all changes made to the
development application since the last GTP. Or put another way, it shows
exactly how the current development and production applications differ. By
studying the information given here, you will be able to establish what effect
the GTP will have on the production application.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
•
The initial screen lists certain changes, including model changes such as
added or deleted cubes or dimension items.
•
You can click Advanced to view more detail and show other changes – note
that the advanced screen might contain details of changes even if the initial
screen is blank. Please see the Contributor Administration Help for good
examples of the kind of information given in the Advanced screen.
•
Pay particular attention to changes that could affect production data – for
example, cubes or dimension items deleted, cells set to No Data by access
tables, and so on.
5.3
5.4
10
Invalid owners and editors and e.List items to be reconciled:
•
The Invalid owners and editors tab only appears if details were requested in
the initial Options step. It enables an administrator to establish whether any
Web client users will lose data if they commit to GTP. Details are given in the
Contributor Administration Help, but in contrast to what is stated in the Help
file, it is worth noting that “editor lagging” simply indicates that a user is
editing at the time. The user will only be “bounced” if the user meets the
conditions described in the Help file – for example, if the user is editing an
e.List item from a version of the application older than the current production
application.
•
The e.List tab appears automatically if any e.List items need to be reconciled
as a result of changes made in the development application. It lists those
e.List items that need to be reconciled and indicates the owner and editor of
those items. It also indicates whether an import data block exists for the
e.List item (this might be the only reason that the e.List item requires
reconciliation).
•
It is important to check the content of this screen, as reconciliation can affect
active Web client users.
GTP Wizard – GTP
If cut-down models are enabled, a Cut_Down_Models job will run automatically at
this stage to generate the required cut-down models. A screen will appear, allowing
you to monitor the progress. This is an equivalent of the normal Job Management
screen except that it is “modal” – i.e. it cannot be closed and you cannot access any
other Contributor functionality while it is open.
In Contributor 7.1, if cut-down models are used, a cut-down job will always be run at
this stage, and all cut-down models will be regenerated. This is because (virtually) all
information relating to the model is held in a model definition, so virtually any
development change will require the model definitions to be regenerated.
Contributor 7.2 will not generate any cut-down models in two special cases where it
recognizes that the model definition will not have changed:
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
11
1. The only change made in the development application is the creation of
import data blocks, i.e. the only change made was to complete an import
process and/or run Analyst to Contributor D-Links.
2. The only change made was to existing translation strings.
Note that new cut-down model definitions are produced before the end of the GTP
process, so that they are available to Web client users as soon as the new
application is available.
Backup
If a backup was requested in the initial Options step, it will be performed now.
Pre-production process
The pre-production process does as much work as possible to prepare for the GTP
process, without truly interacting with the production application. This is primarily in
order to keep the GTP process itself as compact as possible. Remember that at this
stage, the production application has not been replaced by the incoming
development application – it is still functioning normally for the Web client users.
Certain error trapping takes place so that invalid application definitions are
intercepted before any attempt to put them into production. For example, GTP will
be stopped if there are no e.List items or no users defined.
A master model definition per language is produced.
Any new e.List items are added to database tables. Note that data blocks for the new
e.List items are not created until they are “initialized” as part of the reconciliation
process.
Development import data blocks are “moved” into the production application. Strictly
speaking, they are simply re-labeled so that they are now associated with the
incoming production application.
GTP process
First, both the development and production model definitions are unpacked and
loaded into memory. Note that this can take some time (up to about 10 minutes),
especially if the e.List is large.
Contributor 7.2 takes advantage of the fact that the model definitions are open and
now performs a test reconciliation on two e.List items, in order to intercept possible
problems (the most common reconciliation errors tend to occur when the first e.List
items are reconciled). This test reconciliation should only take a couple of minutes.
Now the GTP process is ready to perform the actual switchover from the
development to the production application. As this will interact with the run-time
production application, the application is made unavailable to Web client users before
this process starts, and only made available again when it is complete. The duration
of time varies depending on structure. The Web client users will not be able to
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
12
interact with the application in this phase, but the Web client is coded in such a way
that they should be completely unaware that anything unusual is happening.
Workflow states are updated for all e.List items, including any new e.List items
added by the pre-GTP process.
Note that the fundamental definition of the e.List is held in the model definition(s).
This means that new e.List items can be added to database tables in a preproduction process and deleted items can be removed in a post-production process,
which helps keep the GTP process itself as compact as possible.
Development model definition(s) are put into production and become the new
production model definitions. Old production model definitions are not necessarily
deleted at this point as they might be required to support the reconciliation process.
The model “version” is incremented and the new production application is fully
committed.
In Contributor 7.2, all o these changes are implemented as a transaction which will
be rolled back automatically in case of any problems.
Post-production process
The post-production process performs tidying-up operations on the database, which
can be conducted in a relatively leisurely fashion now that the new production
application is available. Strictly speaking, they are all non-essential.
•
Irrelevant jobs are removed (e.g. Publish jobs for the previous production
application), so they will no longer be seen in the Job Management screen.
•
Any deleted e.List items and associated data blocks are removed from
database tables.
The two operations above occur before the message indicating that GTP is complete,
whereas the jobs listed below will be queued by GTP, but might continue to run after
GTP is complete.
•
An Import_Queue_Tidy job removes old import data blocks relating to the
previous production application.
•
A Cut_Down_Tidy job removes redundant cut-down models relating to the
production application before the previous production application (cut-down
models relating to the previous production application are kept to support
client-side reconciliation).
•
Contributor 7.2 only: A Validate_Users job checks that the current owner or
editor of an e.List item can still access the e.List item. This was introduced in
7.2 due to support for security integrated with Access Manager. Prior to this,
all user rights information could be derived in the development application
and held in the model definition.
•
Contributor 7.2 only: A Language_Tidy job removes redundant copies of
translations associated with the previous production application.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
13
Finally, if reconciliation is required, a Reconcile job will be queued. It will start
automatically, providing job server(s) are started and set up to monitor the
application.
Reconciliation
The reconciliation process will update data blocks as necessary after GTP. It is
handled by a Reconcile job, which is automatically queued when GTP is complete.
The following development changes will require reconciliation:
•
A synchronize with Analyst has been performed. All e.List items will require
reconciliation: all data blocks for contribution e.List items will be
“restructured”, and all Review e.List items will be re-aggregated.
•
Changes have been made to Access Tables, Saved Selections, or the e.List
that result in a different pattern of No Data cells for any contribution e.List
items that are common to both the development and production applications.
All e.List items will require reconciliation: all data blocks for contribution e.List
items will be “restructured”, and all Review e.List items will be re-aggregated.
Please see the Contributor Administration Help for more information.
•
An import has been performed (or Analyst to Contributor D-Links have been
run). Any contribution e.List items with import data blocks will be reconciled:
the import data blocks will be combined with the production data blocks. Any
Review e.List items whose descendents are reconciled will be re-aggregated.
Note that if you use the Prepare “zero data” option, an import data block is created
for all e.List items, so all e.List items will be reconciled.
e.List items have been added, deleted, or moved to a different review e.List item.
The reconciliation process will create new data blocks for added contribution e.List
items (initialization), and perform re-aggregation of new review e.List items and
review e.List items with changed descendents.
Note that re-ordering the descendents of a review e.List item will not require any
reconciliation.
Reconciliation proceeds through e.List items in reverse hierarchy order. Review e.List
items are reconciled (re-aggregated) when their last immediate descendent has been
reconciled. All operations on an e.List item are completed before the next e.List item
is reconciled. For example, a contribution e.List item could be initialized and then an
import performed.
The reconciliation process will usually run on the server, but in order to offer end
users immediate access to the new application, an equivalent client-side
reconciliation process can run on client machines.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
5.5
14
Warnings
When changes requiring reconciliation of all e.List items (Synchronize and certain
access table changes) are made in the Contributor Administration Console, you will
be warned that a reconciliation will be required if you commit the change:
Reconciliation Warning
If there are prepared import data blocks, you will also be warned that these will be
deleted if you commit the change (as they might no longer be valid with the new
data block structures):
Delete Import Queue Warning
Generally speaking, reversing a change requiring reconciliation after it has been
saved in the development application will not prevent reconciliation. However, import
reconciliation is only performed for e.List items with import data blocks at the time of
GTP. No e.List items will require reconciliation due to import changes if the import
queue is deleted prior to GTP.
5.6
Client-side-reconciliation
Client-side reconciliation is provided in two cases:
1. A user attempts to open an e.List Item after GTP but before its data block
has been reconciled on the server – client-side reconciliation can update the
data block on the client before presenting the user with the updated model.
2. A user is already working on an e.List item (editing or annotating, on or
offline) at the time of GTP – client-side reconciliation can update the open
model to the new model without losing any unsaved data or annotation
changes. Client-side-reconciliation will be triggered when the user attempts to
take an action requiring connection with the server (e.g. Save, Submit, or
Work Online), or when the client polls the server at the interval specified in
the Contributor Administration Console.
There are certain restrictions to be aware of:
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
5.7
15
•
Client-side-reconciliation is only provided for contribution e.List items (as the
key principle is to avoid data loss). Web client users will not be able to open
Review e.List items until they are fully reconciled (re-aggregated) on the
server. A Web client user who is annotating a review e.List item at the time
of GTP will lose any unsaved annotation changes.
•
A user with only view rights to an e.List item cannot perform client-side
reconciliation. The user will have to wait for the e.List item to be reconciled
before opening it.
•
It is not possible to open a multi e.List item view if any of the e.List items
within it require reconciliation.
•
Reconciliation for a user already working on an e.List item is only possible if
the user is working on a model belonging to the old production application,
i.e. the application that was in production prior to the GTP. If they are
working on a model version older than this, they will not be able to perform
client-side reconciliation and will not be able to save any unsaved changes.
This is much more likely to affect users working offline than those working
online.
E.List items not requiring reconciliation
A user can be working on an e.List item that does not require reconciliation (for
example an import has been performed which does not affect this e.List item).
Although the data block does not need updating, there is a new model definition
which must be incorporated. When the user attempts to take an action requiring
connection with the server, or when the client polls the server, a message like this
will appear:
Application Definition Changed on Server Warning
The same sort of thing is experienced by users working on e.List items at the time of
GTP, if the GTP requires no reconciliation at all.
6 Backup processes
You should always implement a backup regime as part of the process of making and
committing changes.
You will probably want to back up an application on a regular basis, in case of a
failure in a production application. Providing backups are taken fairly frequently, at
known times, it is usually practical to restore to a point in time and have Web client
users re-make any changes they made since this time.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
16
In addition to scheduled backups, it is highly recommended that you back up an
application immediately prior to GTP.
6.1
Mid-GTP failures
Failures occur within the GTP process itself. Problems here are very uncommon but
are potentially serious as the development application will be in a semi-modified
state and is likely to be unusable. If you experience a failure during GTP, you can
restore the backup taken immediately before GTP. Providing the interval between the
failure and the restore is not great, Web client users will not be inconvenienced and
they should not lose any data. It is sensible to take the application offline (or stop
the Web server) until the backup is restored.
An attempt to repeat the GTP might or might not succeed. Normally a failure is due
to environmental problems such as hardware or network problems. If this is the
case, then GTP should succeed if re-tried after the fault is rectified. If the failure is
associated with the development application itself (a corrupt model definition or
import data block, for example), then you will probably have to undo changes made
to the development application, by resetting the development application to
production. (You could also remove just the import data blocks by going to the
Prepared Data Blocks tab in the Import screen and choosing Delete Import Queue.)
Every effort is made to minimize the risk of mid-GTP failures. The GTP process where
the development and production applications actually come into contact is kept as
compact as possible, and GTP performs various checks on the incoming development
model to establish its validity before putting it into production. Contributor 7.2 has
further improvements. For example, development changes are committed as a
transaction which will be rolled back automatically in case of problems. Work to
minimize the possibility of mid-GTP failures is ongoing. If you experience any
persistent mid-GTP failures, it is important to send a backup of the problem
application to customer support for diagnosis.
6.2
Reconciliation failures
A failure during post GTP reconciliation should not render the production application
unusable, but will leave it in an inconsistent state (i.e. with only some data blocks
updated).
If a reconciliation fails, the reconcile job is cancelled. To restart the reconciliation,
just GTP again – the reconcile job will automatically resume at the point where it
failed. Note that you will not be able to perform a new GTP while there is an
incomplete reconcile job – any attempt to GTP will simply attempt to restart the
reconcile job.
The most common cause of reconciliation failures is environmental problems. If
these problems can be addressed, then you can simply resume the reconciliation.
In other cases, reconciliation can fail due to a problem with the application itself.
Most frequently this will cause reconcile to fail immediately – i.e. when attempting to
reconcile the first e.List item. Such problems should be intercepted in Contributor 7.2
as a test reconciliation is performed on two e.List items during the GTP process.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
17
Less frequently, reconciliation might fail after some number of e.List items have been
successfully reconciled. The most common problem is that there is insufficient
memory on a job server to perform aggregation of a review e.List item. In these
cases, reconciliation might succeed if more memory can be provided (or if the
aggregation is handled by a different job server with more memory). However, with
wide hierarchy branches and large models, the aggregation might require more
memory than can actually be addressed. In these cases, the e.List or model will need
to be changed before reconciliation can succeed. Again, this should not be an issue
in Contributor 7.2, due to changes made in the reconciliation aggregation routines. It
is also possible that there is a problem with an individual e.List item, which means
that it cannot be successfully reconciled. For example, an individual data block or
import data block could have been corrupted.
In the event of a reconciliation failure, the following is recommended:
1. When a reconciliation fails, the reconcile job will be cancelled. There is a
chance that job executors will have been stopped, so always check they are
started before attempting to run any more jobs (for example, by choosing
stop and start in Monitored Applications)
2. Take the application offline. This stops further Web client interaction with the
application, thus minimizing the amount of changes which could be lost –
some problems can only be resolved by restoring the pre-GTP backup. If you
have encountered such a problem, then leaving the application online will
only result in further data loss.
3. Take a backup – but ensure that this backup does not overwrite the normal
Contributor backups! You are unlikely to restore it in order to resume the
reconciliation (though this is possible), but a backup at the point of failure
can be invaluable for debugging purposes.
4. Check where the reconciliation failed. A straightforward way to establish this
is to look at the production Preview screen in the Contributor Administration
Console (where the workflow icon for un-reconciled e.List items is enclosed in
a red square).
5. Try to establish the cause of the problem. If the problem is environmental
and can be addressed, then the application can be put online again, the
problem fixed, and the reconciliation re-run.
You can either choose GTP immediately, which will automatically resume the
incomplete reconciliation. Or, if there has been little Web client activity since GTP,
you can restore the pre-GTP backup and GTP again.
If the problem is not environmental, then the application will have to be changed if
you need to GTP again:
1. Restore the pre-GTP backup. At this point the application can be put back
online.
2. Reset the development application to production. (The development
application will now match the current production application).
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
18
3. Re-make selected changes in the development application.
4. GTP again.
If Web client users have saved data between the GTP backup and the point of
failure, then this data will be lost when the backup is restored. But bear in mind that
before restoring the backup, you could contact the Web client users and give them
the opportunity to perform a local save of their changes, so that they can re-load
them after the restore.
If you are not sure what caused the failure, it might be worth attempting to re-run
the reconciliation. It could succeed if there was a temporary environmental problem.
Alternatively, it could help you diagnose the problem.
If you resume a failed reconciliation, it might appear to make further progress before
failing again. In this case, it might be tempting to keep re-trying the reconciliation.
But bear in mind that a resumed reconciliation might find extra work to do before
actually going on to fail at the same point. So always check where reconciliation has
failed. You will not make any real progress by re-running a reconciliation if it always
fails at the same point – you are probably just postponing a database restore,
thereby actually causing further data loss.
7 Analyst
It is recommended that you always backup an Analyst model after making changes
and performing a Contributor synchronize. The Contributor pre-GTP backup is not
really complete without a backup of the Analyst model after synchronize – the
Analyst backup represents the Analyst model used to create the Contributor
application. The Analyst post-synchronize backup and the Contributor pre-GTP
backup form a “pair” – you could restore this pair to roll back an application to an
earlier model version.
Remember that you might have to back up multiple Analyst libraries, as Contributor
7.1 and later support multiple-library Analyst template models.
Also note that in Contributor versions prior 7.2, Contributor synchronize made
changes to the Analyst model – it added GUIDs to Analyst objects and D-List items.
Model backups before and after synchronize would not be identical, and a presynchronize backup would not be the true partner of the Contributor pre-GTP
backup.
Analyst 7.2 now assigns GUIDs itself, so synchronize in Contributor 7.2 no longer
needs to make any change to Analyst models created in Analyst 7.2. For Analyst
models created in earlier versions, the situation is a little more complex: Contributor
synchronize will still have to assign GUIDs to any object that has not yet been
opened and saved in Analyst 7.2.
If you experience any persistent mid-GTP failures, it is important to send a backup of
the problem application to customer support for diagnosis.
IBM Cognos Proprietary Information
Go to Production in IBM Cognos Contributor
IBM Cognos Proprietary Information
19
Fly UP