0. Motivation
IFBC-Log provides a huge bunch of information and sometimes it is hard to read and understand it. This document gives some more insight in the way how the log can be used.
1. Notes
- Consider the screen shots below just as examples. They may be different in your system depending on your release, support package and note implementation status.
- This document concentrates on product engine msg.PM. But most statements are true for product engine FS-PRO too.
- The statements of this document are quite general and they do not refer to a specific release. Probably you will miss features and artefacts in certain releases. But this does not invalidate the general idea behind the way how the log should be read.
2. Overview
The log consists of a lot of tab strips each covering a different aspect of IFBC import.
The first block out of three is about import of products:
The second block is more related to PBT and special aspects of the Insured Object in PBT:
The third (and last) block is about import of listing values:
Here once more the list of tab strips:
- Template Overview
- Summary
- In-Force-Business Configurator - the destination
- msg.PM - the source (could also be FS-PRO)
- Import Locks
- PBT
- Insured Object
- Customizing Overview
- msg.PM - Listing Value
- C-Tables
- E-Tables
- S-Tabels
- Fixed Values for Domains
3. The Tabs in more Detail
3.1 Template Overview Tab
This is - to my opinion - one of the most important tab strips:
IFBC content is stored in eight tables and the overview reports about all changes in these tables due to IFBC-import (the result is the same for simulation and update run):
- Templates
- Template short texts
- Attributes
- Cardinalities
- Characterstics
- Default Values
- Value Ranges
- Business Processes/Business Transactions per Template
The screen shot above shows that only few data have been changed or added; no data have been deleted. Depending on what has been provided by PSV import, the numbers - of course - will vary.
Imagine you did some minor changes in msg.PM content. Then you can expect few changes is IFBC content too. On the other hand imagine you created a new sales product in msg.PM. Then you will have many new entries in IFBC because new templates along with new attributes and new characteristics etc. will be created.
During your work you should develop a feeling of the consequences in IFBC if you work in msg.PM of in PBT.
It is important to understand that IFBC-content can be changed in at least two ways: Due to an import of products (the most prominent use case) or due to changes in PBT.
The most prominent place in PBT which is relevant for IFBC are the channel models and the attributes therein. If you change, for instance, the property "Default" in the IFBC-Section of an Attribute in a Channel Model, you will usually see many changes for the corresponding Characteristics Attributes in the IFBC-log once you started the IFBC-import after that change.
Let's go back to the example above and dive a little bit deeper. If you double click on one of the lines more details will be displayed for the selected table. The next screenshot refers to the table for Default Values:
Two entries have been added (the first two lines) and two entries have been changed (the last four lines).
Changes are always displayed in two lines where one line displays the old content (marked with the red minus sign - because the old content will diasppaer) and the other line (the line above marked with the green plus sign) displays the new content. The screen shot shows that the default value of characterstic OBJCAT_CD has been changed from 00009 to 00003 and OBJTYP_CD has been changed from 90000 to 30002.
The next example show a typical "change-log" for the attributes-table:
The table for Attributes contains two sets of information:
- Static Attributes as can be maintained ot the "Attribs"-tab in IFBC maintenance UI.
- Template properties (aka "Basic Data") like "Entity ID", "Product Engine" etc. In particular, the "last changed on/by"-information is also stored in the table for Attributes.
This example shows that "last changed on/by"-information has been updated because some other template property (here, amongst others, the default values for OBJCAT_CD - see above) has been changed. Consequently you should expect entries in Attributes-table even if you did not change any attribute on msg.PM side.
Tip: even if you did not change attributes in msg.PM before the import, you will probably see changes in the attributes-table because, amongst others, administrative information like "last changed on/by" is stored in that table.
3.2 Summary Tab
The summary tab provides you with a high level overall result of the import. The number of messages is always small - around ten or less. The main message here is, that the import for products and listing values has been started as update run and it has been really executed as update run which includes database updates.
This tab really needs to be green if you want to be sure that something has been written to data base in case of an update run. A red icon indicates that either the whole import has been aborted or it has switched to simulation mode (if it was started as update run).
Reasons for error on this tab usually are
- lock issues
- transport request issues
- authorization issues
- infrastructure issues
Rule of Thumb: there are only few resons (in essence those listed above) which either make the import fall back to simulation mode or make the import/simulation stop. The import/simulation tries to 'survive' as long as possible.
3.3 In-Force Business Configurator Tab
The In-Force Business Configurator Tab (IFBC-Tab) represents the 'destination' side of IFBC import.
This tab usually holds a huge bunch of information with respect to
- IFBC content before import
- the import step itself and
- the IFBC-content after import.
The log is quite verbose:
This log is organized according to different phases during import. It begins with setting some parameters controlling the import process, loading and checking IFBC-content, execution of import, doing checks and automatic steps after import and, in case of update run, writing data back to IFBC. This log covers all aspects of import of products on IFBC side. The source side (msg.PM or FS-PRO) will not be considered here.
One issue here is that in some cases the severity of message might be considered differently by different customers. Therefore, from time to time we re-evaluate the messages and sometimes we remove messages completely or we reduce the severity.
In the example above a lot of templates are in status 'in process' which needs to be logged.
3.4 msg.PM tab
The msg.PM tab represents the source side. Like with IFBC-tab, this tab is also organized in multiple phases beginning with checks of parameters, checks of product delivery, some 'self healing' and the import from the source perspective.
In general we don't observe many 'red' entries here. The only exception from this rule is the import of new cardinalities (import of the hiearchy). In case a child template needs to be added to a parent template, the system will create a log entry if the child template can not be determined uniquely from the product-node-ID (OID) on msg.PM-side. This happens, if two or more templates refer to the same product-node-ID. The root cause for this situation is that such a template has been copied because copying must keep the product-node-ID of the original template. In other words: after having copied a template two templates have the same product-node-ID. Consequently the child template has to be selected and added manually to the parent. Once this is done this issue will no longer occur.
3.5 Import Locks Tab
IFBC offers the option to override properties of templates which have been imported before. In order to protect these changes against subsequent IFBC-imports, import locks can be set. These import locks are available on a quite granular level. The log of Imort Locks reports about existing locks.
Import locks can be set for
- template text
- Attribute value
- Characteristic Attributes
- List-ID of a Characterstic
- Default Value of a Characterstic
- Value Range of a Characteristic
- Cardinality
This log simply reports about existing import locks.
In general it is worth thinking about removing the locks unless there is a good reason not to overwrite the locked property during subsequent imports. On the other hand there is a certain probability that especially import locks for Characteristics Attributes must exist because the default determination algorithm ends up in values which do not fit to your business need. Keep in mind that automatic setting of Characteristics Attributes in the standard is just a best guess.
3.6 PBT Tab
3.7 Insured Object Tab
3.8 Customizing Overview Tab
3.9 msg.PM Listing Value Tab
3.10 C/E/S-Tables Tab
3.11 Fixed Values for Domains Tab
4. Some recommendations for log processing
In the sub chapters above i have explained a little bit the log along with some typical messages. In this chapter i will give some advice for what to do if certain messages show up. The list will - of course - be incomplete.
- Make sure that all templates exist in status 3, 'released'.
- Avoid having templates in state 1, 'in process' during import - otherwise there is a risk that once this template will be released it does not reflect the situation in msg.PM.
- Avoid copying of templates and product trees if possible - otherwise you potentilly need to assign child templates manually.
- Keep the number of import locks small - otherwise you decouple more or less from msg.PM