IFBC and the Log
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.
- 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.
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
- In-Force-Business Configurator - the destination
- msg.PM - the source (could also be FS-PRO)
- Import Locks
- Insured Object
- Customizing Overview
- msg.PM - Listing Value
- 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):
- Template short texts
- 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
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.
IFBC-Import supports automatic removal of import locks. However this feature is not supported for all types of locks. Please read the F1-help.
3.6 PBT Tab
The PBT-tab marks the begin of the second group of tabs. Since PBT provides information consumed by IFBC import, we decided to perform some checks there. Mainly it is about compatibility between Attributes of Channel Models and Components of DDIC structures. Each Attribute of a Channel Model needs to have a Component in the underlying DDIC structure.
This screen shot shows the case that a Component is missing in DDIC structure.
Tip: try to remove all errors which you have under control.
3.7 Insured Object Tab
This tab is also related to PBT but it concentrates on the so called Insurad Object, which needs special treatment:
The insured object and its representation in PBT needs additional checks because multiple DDIC-structures and Channel Models are involved.
The most relevant Channel Model (and DDIC-structure) is /PM0/ABWASUBJCT. This model (structure) comprises ALL attributes (components) of all object types and object categories. Thus /PM0/ABWASUBJCT is the source of truth regarding all IFBC-relevant information.
3.8 Customizing Overview Tab
3.9 msg.PM Listing Value Tab
3.10 C/E/S-Tables Tab
In case you are not familiar with the so called delivery classes C, E and S, here a brief introduction.
The content of a C-table belongs completely to the customer. If SAP delivers C-table content, it will end up in client 000 only. Customers may review that delivery and decide to use or not to use the content in their clients and applications.
The content of S-tables, in conrast, can be considered to be like coding. The content belongs to SAP and each change in a S-table is a modification. S-table content is delivered to all active clients in a customer system. S-tables are often calles 'system'-tables. It is allowed to 'program' on S-table content.
Somewhere in between are the so called E-tables which are logically split in two areas. One area belongs to SAP and the content is delivered like that for S-tables. The other area of an E-table belongs to customer giving him the option to extend that table. That area is like a C-table. The key of the table will usually be used to distinguish between SAP-standard and customer contribution. Customer key often begin with Z, but deviations may occur. The exact customer namespace is defined along with the E-table definition.
3.10.2 Import of listing values
Listing Values aka Enumeration Values are defined in msg.PM and therefore they will be imported to IFBC. In principle, the tables storing the listing values are usual customizing tables (often, but not always C-tables) consisting of a table which holds the keys and a second table which holds the language dependen texts.
During the import the following situations may occur:
- The import leads to creation of a new entry in key table and/or a new entry in text table. This will be done automatically for C tables and for E-tables in customer namespace. The attempt to create an entry in a S-table or in SAP-namespace of an E-table will be rejected and ends up in a red log entry in S-Table or E-table tab respectively.
- The import leads to update of an entry in the text table. By default, any change will not be executed automatically. Neither in C-tables nor in customer namspace of E-tables. Optionally you can allow overwriting (for C-tables and for E-tables in customer namespace) by setting the checkbox "Overwrite Listing Values Texts" on the entry screen for the import or simulation. Every table change which could not be done automatically results in a log entry in the corresponding tab with the instruction what to do.
- The import leads to deletion of an entry. IFBC-import never deletes entries during import of listing values and there is no option to allow it. Deletion needs to be done manually after reviewing the log entry. Deletions may harm already existing policies in the system. In general, the attempt to delete a listing value is an indication that the entry is probably missing on msg.PM side. The other use case is that you are developing a new product and you have changed your mind concerning the content of the list. Then you probably can delete the entry from the customizing table. The system can not distinguish between these two situation automatically - therefor the need for manual rework
3.10.3 Other tables
Normally, the tables storing the listing values and the accompanying texts consist of the following fields:
- Key table: Client, List-ID, Key - all fields are key fields
- Text table: Client, Language, List-ID, Key, Text - all but the last field are key fields
There are also few tables where e.g Client is missing, List-ID is missing or where further fields exist. With these tables the system will do a best guess.
A table with more fields is TCURC, the table of currency codes. At a first glance you might think that manual post processing is required. But imagine the following use case: The 'relevant' parts of TCURC have somehow been replicated to msg.PM because the product developer has decided to refer to those currency codes, which exist in SAP system. Then the currency codes (along with their texts) will be stored in listing value tables of msg.PM. Sooner or later, a compilate will be created which contains, amongst others, lists of currency codes. IFBC then would try to import the listing values to TCURC - but due to the 'unusual' DDIC definition, it would just report in the log about the attempt to add/change/delete table rows.
3.11 Fixed Values for Domains Tab
This chapter can simply be summarized as follows: IFBC import NEVER will do any change on fixed values of a domain.
4. Some recommendations for reading the log and processing its messages
In the sub chapters above i have explained a little bit the log along with some typical messages. The messages may be red, yellow or green and in particular the red ones unfortunately make the reader worry. It is important to understand that red log entries do not necessarily lead to import errors. In general the system proceeds and applies some best guess logic.
Example: Sometimes the system discovers orphaned table entries - this are entries belonging to a template which does not (or no longer) exist. The corresponding log entry is 'red' but the system will simply delete that entry automatically. The entry is 'red' because we believe it is important to report about this finding and to find out why such an orphaned entry came into existence; but this does not mean that the system gives up or breaks down.
ABAP developers, for example, are familiar with a tool called CHECKMAN or ATC. Even if your ABAP code is syntactically correct, CHECKMAN/ATC will find other errors which require post processing. You should read the log more like the ATC/CHECKMAN instead of a compiler log where a single error makes the compile process fail.
Finally some advice which probably helps to reduce the number of log messages. The list is - of course - 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
- Ideally, the product developer who is working in msg.PM has access to the IFBC log in order to review the outcome of his (of her) work in msg.PM. Therefore this person needs to have some basic knowledge about IFBC. You will run into difficulties if product developers and IFBC experrts are not working closely together. If product developer and IFBC-expert are different persons make sure that they sit close together in the office.