- Summary:
- Restrictions & Disclaimer:
- How to optimize:
- Low effort changes on code level:
- Move from 32bit to 64bit msg.PM Designer
- Changes with implementation efforts:
- Avoid usage of huge rating tables
- Split up product catalog
- Preconditions
- Guiding Principle
- Recommended Strategy
- Preconditions for using Multiple Compilates Feature
- Deployment strategy for Multiple Compilates
- Points of Notification
- msg.PM Designer and reuse of basic libraries in a multi-designer environment
- External tables in transportable SQLlite format
- Guidance for Caiman check
- Problem Description
- Solution Description
- Preconditions to be met
- Possible Workflow of Development Process
- Action Items
- Automation (optional)
- Implementation of the CAIMAN Pre-Checks
- PSV Import
- Mass Import
- Implementation support:
Summary:
The following document will describe the overall data flow how the products designed in msg.pm designer tool will be sent to the FS-PM Inforce Business Configurator. In system with a small amount of products with a low variantion, the process at all is rather fast. With an increasing number of products and a higher variant of lines of business, in combination with huge internal rating tables to validate values, the runtime of the E2E process is getting slower and slower.
The given process flow has 4 critical and time consuming elements
1) Generation of the msg.PM compilate
2) Manuel efforts to fix error
3) Validation of compilate against SAP (Caiman activity )
4) Import the data to SAP FS-PM (PSV & Mass Import activity)
Of course the release of new products in a productive insurance company is a monthly, quartely or yearly one time process, but in an agile implementation phase of a new project, in combination with different teams working on different sales products at the same time, the organizatonal tasks to be scheduled can have a negative impact.
WIthe the following best practice you will get a faster performance of the E2E process. It is also a guideline how to avoid future upcoming performance losses but also guides you how to make an smooth setup depending on business needs.
The solution approaches follow the simple strategy of running faster by
- working with SQL optimized code
- working with smaller units
- devide and conquer
- organizational development process sync
Hints:
If you already know at the beginning of the project the overall final number of products and a extreme huge number internal tables (rating tables) is in place
then
- Install the 64bit Version of the msg.PM designer including all Windows clients on 64bit OS
- Design your products using EXTERNAL tables from the beginning
- Setup your msg.PM Designer using a HANA DB How to install msg.pm on SAP HANA
- Avoid complex product template inheritages in all cases
- Avoid massive use of reuse libraries across LoB products
More in the blog The golden rules for a successful msg.PM deployment process to FS-PM
If you didn't followed the golden rules find improvement options below.
And always remember "If you don't do it right from the beginning, in most cases you have to do it twice."
Restrictions & Disclaimer:
The described solutions are based on the latest FS-PM 5.3 release and the latest availble msg.pm designer. It might be possible that code changes will be come obsolete because they are already part of a support package.
The described guidlines can be implemented at your own risk. Implementation depends on customer situation and business needs.
How to optimize:
Low effort changes on code level:
- The easiest way to optimze the import time on FS-PM side is the implementation of the following notes
The performance influencing factor of the FS-PM import is the number of characteristics sent by msg.PM Designer. So it is strictly recommend to limit the overall number of characteristics and characteristic values. With an average system the core import is able to handle ~200 characteristic value per second + an overhead for preparation and persistency of data.
- In a parallel development process of new sales products, the unsyncronized release might lead overwrites of the import queue. If in parallel the FS-PM Import process is started, the execution can access incomplete or not up to date content. Please implement following notes.
These notes will introduce a new locking concept to avoid potential inconsistent sitautions. They are the precondition for the guidance implementation working with smaller units handled as multiple compilates.
- Implementation of the patch 7 for msg.PM Designer 3.4.10.1
This patch will optimize the database load performance for internal tables. Now a bulk-load functionality for table rows was implemented as a result the load time could be reduced by factor ~70 (estimated, not guranteed)
Example:
| Exporting item | Patch 2 time cost | Patch 7 time cost | |
| Exporting around 300 products with 10 Million data. | Load data rows | 40min | 7min |
| Compiling | 46min | 44min | |
| In total | 86min | 51min |
In the given example the core runtime to compile is more or less unchanged. Additional optimizations will not lead to a tremendous runtime improvement. It is strictly recommended to divide the compilates by sales products to handle smaller packages.
Move from 32bit to 64bit msg.PM Designer
You may ask if this move is needed. And the answer is yes because in huge product environments it will be very easy to reach the memory limit. So one way out is either to use only external tables, to keep the data processing small or increase the adressable memory. Also for a smoother handling we recommend to install the 64bit version of the msg.PM designer.
If you have already the 32bit version installed, there is no upgrade path available. You have to DEINSTALL and INSTALL the whole thing. But some preconditions are needed
- All Windows PC client must run a 64bit Windows version
- Your DB must have installed a 64bit ODBC driver
Please follow chapter 5 of the Deinstallation/Installation in the Installation Guide of msg.PM Designer
Changes with implementation efforts:
Migration of huge internal rating tables
Introduction
This chapter describes exemplary how to migrate internal tables from PM.Designer to external tables in an external database management system (like Microsoft SQL Server) using Microsoft Access.
Preconditions
The implementation of the following steps makes sens in case you have internal tables in msg.PM Designber with a row count >8000.
We recommend to convert in a first step only these tables.
After a successfull implementation and a validation if the export runtime is still too long, please repreat the implementation for all internal tables >5000 entries.
Prerequisites
The following software is required:
- PM.Designer
- Microsoft Access
- External Database Management System like MS SQL Server, IBM DB2, Oracle
- ODBC Connection to the external database which will contain the external tables
Example – step by step
Actual State: For example an internal table with name “InTab_InsuredAge_MaxUnits_15URWL_Q2”
Target: External Table with same layout and data content
Actions for Migration:
1. Create a new table with the same layout in external database management system, for example Microsoft SQL Server, see screenshot below.
2. Configure new ODBC connection to the external database.
In case of 32bit Microsoft Access the 32bit ODBC configuration tool has to be used:
c:\Windows\SysWOW64\odbcad32.exe
For 64bit Microsoft Access the corresponding 64bit ODBC configuration tool:
c:\Windows\System32\odbcad32.exe
3. Open Microsoft Access and connect to the database via ODBC.
Choose second option “Link to…”
Select your ODBC data source. (in our example the PMEXTTAB)
And the previously new external Table with the name “InTab_InsuredAge_MaxUnits_15URWL_Q2”:
The empty table will be shown in Microsoft Access.
4. Export the table data in PM.Designer as csv.
Continue wiuth the internal table and use the export functionality to create a CSV file.
Save this file at a place where you can find it again.
5. Import the csv file into the new external table in Microsoft Access.
Import the CSV file into your previously created DB table schema
Define the format of the CSV file
and select a semicolon as defined delimiter
Click on Finish and wait until process is completed
After clicking on "Finish" the data of the import will be displayed
6. Recreate the link in msg.PM Designer
Rename the old internal table and create new external table with the same name (InTab_InsuredAge_MaxUnits_15URWL_Q2) in PM.Designer.
This is important because when another name is used M10 formulas won’t work
Click on LAYOUT for your new table.
and point to the new external DB table
7. Check the result
After completion of these steps a single table was migrated from internal to external msg.PM representation.
Please redo these steps for the wished number of tables. Or in case you are defining a new design, think about before.
Please be aware that moving data to an external database will lead to addional organizational steps in maintenance process. The complexity of data maintenance is increased because using an additional external database with an own data maintenance entry.
Also transport of data will lead to a higher risk of missing steps in operation.
Avoid usage of huge rating tables
This is a proactive step in an implementation project to estiamte the potential business change of the future. Within msg.PM runtime it is possible to use precalculated rating tables or implement a financial mathematics formula to calculate premiums on the fly. In best case such formulas are directly implemented in msg.PM. From a generic point of view it is very common to use rating tables in insurance business. We strictly recommend to keep these tables under control from aspect of growth.
Split up product catalog
Divide & Conquer is the next principle for the product export. In a multi-designer environment, the development and maintenance of products will end in a huge single export file. This file or also named compilate needs a long time to be generated. Instead of merging all products into one single compliate, it is also possible to split up the whole product catalog by sales product lines. In this case you have to ensure that entities are not cross used to avoid de-sync of data.
Preconditions
Fhe following holds for Release FS-PM 5.3:
- Product modules, which are used in multiple sales products, must be identical in the different sales products.
- Differences in multiple used product modules can occur, when these product modules are changed and only a part of the content is imported to FS-PM
- MSGPMCON will do the check when importing. (The user can decide to reject the import or import changes of multiple used product modules to the other using sales products)
(Be aware that commonly used Formulas and purely msg.PM-internal tables, which are deployed only in the Compilate, are already completely independently deployable. No issue here.)
Guiding Principle
Principles to consider for Deployment Units (in order of Priority)
A. Keep product sets independent
Minimize interference between different product development streams (to prevent that delay in one stream affects other streams)
Minimize administration and checking effort
Minimize errors, unwanted side effects
B. Maximize granularity of product sets
Straighten the deployment schedule
Straighten the development schedule
Equalize product development workload over time (to optimize efficiency)
Minimize the effect of errors
C. Maximize re-use
Harmonization
Recommended Strategy
As Deployment Units, find small sets of products that have much in common
- Use Logical Grouping
- We recommend that the Deployment Units should not contain more than 10-20 Products
- Inside these sets, re-use Product Objects
- Shared libraries, e.g. Sample Content standard libraries should be included in a Deployment Unit
- No other libraries that are not necessary, should be part of the Deployment Unit
For re-use in different deployment Units, use Product Object Templates instead of Product Objects
- For each deployment set, create a separate object, but derived from this template
Take into account that the msg.PM templates take care of maintenance for all these objects only in msg.PM.
- This might affect the decision on the size of the deployment sets (bigger sets - less double maintenance for commonly used objects in IFBC
- Consider a way to maintain IFBC templates automatically (IFBC template Automation)
Preconditions for using Multiple Compilates Feature
|
A compilate needs to contain at least one complete Sales Product to be deployed successfully
- All information relevant to a Sales Product needs to be available within the same compilate
- (Shared) product modules
- (Shared) formulas and functions
- (Shared) internal tables
- Background: TOMATOSX will calculate requests using one (of the multiple) compilate at a time
Deployment strategy for Multiple Compilates
- Each Deployment Unit (DU) has its own Deployment Satellite
- Development of each DU is independent and can follow TaskID approach
- Deployment for each DU can take place in parallel and independently. Different deployment frequencies possible
- Central overall deployment is also still possible if situation requires
Points of Notification
Products not deleted from FS-PM by removing them from the compilate
It is important to note that the absence of a product within an export can no longer be interpreted as a deletion of that product […]. So once such an independent product is deployed it is not possible to remove it from the product collection anymore. Due to the fact that operative data based on such a product may exist once it is deployed and available in the operative system a removal is not desirable anyway, because it would lead to corrupt operative data as long as such operative data would be dependent on the product.
Shared objects are overwritten by latest import
IBC does not store separate versions of shared objects. This may have side effects on already deployed Sales Products. For the moment this is an intermediate solution and SAP eventually want to provide a solution where different versions of templates can be maintained in IBC. Example: In case a product module that lies within a shared product library is part of two or more Deployment Units, then always the last PSV import overwrites the previous version of this product module even if it was delivered as part of a different Deployment Unit (and maybe different Sales Product).
msg.PM Designer and reuse of basic libraries in a multi-designer environment
In the design of sales products with the msg.PM designer the usage of templates makes sense. The idea to avoid double maintenance and the capability to copy, paste & adapt a product in a hiearchical design is ok as long as the users are not working on the same objects. So called central product libraries shall not be changed as soon as released once. But it happens that product enhancements of bug fixes must be applied. In combination with a multi-server designer environment de-syncs might happen. Either you organize this by a strict governance process of you use the latest feature of msg.PM Designer 3.4.12.0.
In a distributes development environment of msg.PM Designer the concept of master and satelite systems is used. In the master the central repository is used and maintained. Every satelite system is extracting library elements from the master to read or reuse them. In some cases these library entries will be enhanced, modified and must be synced back to the master. If several satelite systems are connected to a master workarea, it was not possible to see if the workarea is already in a potenial update mode. With the msg.PM Designer release 3.4.12.0 a new UI element in the satelite workarea is introduced on the screen of the product libraies. With this button a check can be executed to validate if there are new changes in the master workarea and used data in satelite are out of sync.
The administrator of the satelite system will have a visual indicator and can decide if and when a full sync back can be done.
We really recommend to avoidchanges on re-use library. So please use the authorization concept to limit the number of potential editors.
External tables in transportable SQLlite format
As decribed above it is recommend to keep the size of compilate files as asmall as possible in a 32 bit environment. So the convertion to external tables is recommended to save memory. In a distributed development environment the use of a central external database to handle external tables might nbot work if the designtime and runtime has different locations. It is not recommended to access a cnetral DB with external tables over a WAN connection.
To solve this issue, msg.PM designer is offering a tool called PMTExtTableExport
This tool is able to extract the external tables form any designer environment and created SQLlite files. Thes files can be transported to any other location in combination with the compilate file and will offer the needed data a runtime for the TomatosX Server.
Using external tables will also help to make minor changes in rating tables without full expoort of the whole compilate files (of course no meta data change)
The tool will generate a snapshot of the current state of the DB with the external tables of product definitions. For every external table an own SQLlite file will be generated. For a small about of external tables, we recommend the usage of the GUI.
For a expected larger number of external tables use a batch file of command.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
PMTExtTableExport Copyright © 1997 - 2016 msg systems ag
Usage: PMTExtTableExport <OPTIONS>
- no params - open interactive gui
- Export all tables : </AllTables> - exports all tables
- Export single table : </TableID=> [/DBTableName=] - exports table with specified ID only
TableID : object ID of table to export
DBTableName : overwrites predefined DB table name of table to export
- Export tables matching a pattern: </TableIDFilter=> - exports all tables which ID matches the pattern
TableIDFilter : pattern of object ID for tables to be exported: wildcards * and ? are allowed
- Export a list of tables: </TableIDFile=> - exports all tables which are listed in the specified file
TableIDFile : file path for the file which contains a list of object IDs for tables, only one valid object ID is allowed per line
- Standard options : </Compilate=> </ExportDir=> [/CodePage=] [/CreateIndex] [/AdvConfigTable] [/LogFile=] [/LogLevel=] [/ProceedOnError[=]]
Compilate : specifies compilate file with external tables
ExportDir : target directory, where tables will be exported to
CodePage : overwrites predefined codepage UTF-8, valid codepages are:
UTF-8, CP273, CP500, CP1252, ISO-8859-1, ISO-8859-2, ISO-8859-4, ISO-8859-5, ISO-8859-7, ISO-8859-9, ISO-8859-15
CreateIndex : creates an index for defined key fields in generated SQLite databases
AdvConfigTable : creates an advanced config table, that can be extended with additional information
LogFile : overwrites predefined log file name PMTExtTableExport.log
LogLevel : <Standard|TimeTrace> defines the amount of logging
ProceedOnError : skips erroneous tables, optionally logs their object IDs to specified file
- Database options : [/DataSource=] [/UserName=] [/Password=]
DataSource : overwrites given database name for tables to be exported
UserName : overwrites given DB user name for tables to be exported
Password : overwrites given DB password for tables to be exported
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
To ensure data integrity we always recommend to export ALL TABLES and proceed on error . If you have some experiences how to cacluate a valid delta, us e the additional parameters to optimize the export runtime.
Execute like this: example
PMTExtTableExport /Compilate=d:\temp\XBOL1000.T10 /ExportDir=d:\temp\SQLite /AllTables /ProceedOnError=error_ext_tab1.log
This will export all external tables from DB system and if any table fails the name will be written in the logfile.
Then please fix these tables of the log and redo the job
PMTExtTableExport /Compilate=d:\temp\XBOL1000.T10 /ExportDir=d:\temp\SQLite /TableIDFile=error_ext_tab1.log /ProceedOnError=error_ext_tab2.log
etc until no errors occur
Remark: TomatosX is only able to handle single SQLlite files per table.
Guidance for Caiman check
This chapter will explain how to optimze the development and deployment process.
Problem Description
- Currently CAIMAN check is only performed during compilate deployment process.
- As a result CAIMAN errors are only discovered during Deployment process.
- Since CAIMAN errors are blocking the deployment it is mandatory to fix them.
- Errors need to be fixed in the msg.PM content and a new compilate needs to be created.
This extends the duration of the deployment process significantly in current situation.
Solution Description
- A compilate can be created from each Development Satellite individually.
- Each (Satellite) compilate can then be checked against CAIMAN.
- CAIMAN errors in a Satellite are then detected already within each Satellite
- Check-in to Master must only happen AFTER the CAIMAN test for a Satellite is passed successfully.
Preconditions to be met
- Infrastructure
- CAIMAN tool available on all msg.PM Servers
- Development and Deployment Guidelines Enhancement
- CAIMAN check executed before check-in of new developments into Master
- Satellites are in a compilable state to enable compilate creation for CAIMAN check
Possible Workflow of Development Process
| Step | Time | Task | Responsibility |
|---|---|---|---|
| 1 | Day | Develop product functionality, set TaskID to "Complete" | msg.PM developer |
| 2 | Day | Check TaskID content, set TaskID to "Checked" | Reviewer |
| 3 | End of day | Compile whole Satellite; Ensure Satellite is compilable | Satellite Master |
| 4 | At night | Create compilate | Satellite Master/ Batch process |
| 5 | At night | Run CAIMAN check | Satellite Master/ Batch process |
| 6 | Morning | Evaluate CAIMAN check | Satellite Master |
| 7 | Morning | Approve TaskIDs for Check-in | Satellite Master |
| 8 | Anytime | Check-in approved TaskIDs | Check-in Master |
Action Items
- Install CAIMAN on all msg.PM server instead only on a single deployment server
- Change development guidelines and assign responsibilities
Automation (optional)
Batch-automization of nightly compilate creation and CAIMAN check
- PMBatchUtility
Implementation of the CAIMAN Pre-Checks
After a successful export of the compilate, the content must be validated against an SAP FS-PM installation. For that the CAIMAN tool is used. Any errors found in the CAIMAN checlks will stop the overall deployment process and a rework in the msg.PM designer is needed. So the whole process including in worst case a long runtime to generate the compilat file must be restartet. To catch the most common errors, a plugin was designed for the msg.PM designer to make early checks and avoid the export of the compilate file for an early error resolution.
msg offers an optional msg.PM designer plugin PMCompPlugin_CaimanStarter available from msg-support. This plugin (CPI) on the designer will execute the CAIMAN in a specical check mode and output will directly be written in the msg.PM Designer output window. Optional all results will be written in single logfiles. Statistic information will be written in logfiles.
Evaluation of the logfiles will give the quality manager the possibility how often specific error classes are raised. In this case there is an indicator to establish an error avoidance strategy by traing developers.
The following checks will be done:
PMCompPlugin_CaimanStarter support the COMPILER check (yellow)
FSPM.Desiner-ServerPlugin supports server checks. (blue)
Plugin | Context | Detail |
Server | Product module |
|
Compiler | Product module |
|
Server | Generation / Adjustment Level |
|
Compiler | Generation / Adjustment Level |
|
Server | Relation |
|
Server | HistoryRoot |
|
Server | Class Attribute |
|
Server | Shortname |
|
Compiler | Shortname |
|
Server | Longname |
|
Compiler | Longname |
|
Server | RefModel_Suffix |
|
Compiler | RefModel_Suffix |
|
Server | Object Attribute | Data types “multilanguage string“ and “boolean” are not supported.
|
Server | Method |
|
Compiler | Function | Validation is performed for functions used by methods.
|
Compiler | Array | Validation is performed for arrays used by object attributes.
|
Compiler | Enumeration | Validation is performed for enumerations used as value provider by object attributes.
|
Compiler | Internal Table | Validation is performed for internal tables used by object attributes and for imported internal tables.
|
Server | INTAB_EXP_ |
|
Server | Structure folder |
|
Compiler | Performance | The following performance conventions need to be adhered:
As an exception to this convention, the “hidden” flag from the “internal” object attributes “TaxAmount”, “TaxRate” and “InterestAmounts” may not be set. |
Compiler | BehaviourVariant |
|
FSPM.Desiner-ServerPlugin
The provided DLL file FSPMDesignerServerPluginUCR.dll represents a server plugin to realize several checks for object data in PM.Designer. The file has to be copied to the bin\ directory of the PM.Designer server installation.
Registration
A server plugin is developed as normal DLL Inproc COM component. Analogously to any other DLL Inproc COM component, the component must be registered at the PM.Designer server computer.
The first step is to register the DLL FSPMDesignerServerPluginUCR.dll.
regsvr32.exe FSPMDesignerServerPluginUCR.dll
To deregister a server plugin, the function hve to be called with the parameter /u. regsvr32.exe /u FSPMDesignerServerPluginUCR.dll
Afterwards in PM.Designer server monitor the server plugin with name “FSPMDesignerServerPlugin.FSPMCheckPlugin.1” and CLSID “{ac3bb2a8-501d-41ec-984914b56ab521e3}” can be installed.
How to register server plugins is described in ..\Documents\english\Administration\pdf\PMMonitor_34.pdf.
There are several properties that can be set for the installed plugin:
- Languages: A semicolon separated list of 3-letter ISO codes to specifiy which of the languages of multilanguage data should be checked (all others will be ignored), e.g. “DEU;ENG”. If left empty, then all languages of the multilanguage data are checked by default.
- CheckAllArrays: Values 0 (false) and -1 (true): If set to true, also data checks for arrays are executed (see next chapter).
- CheckAllEnums: Values 0 (false) and -1 (true): If set to true, also data checks for enumerations are executed (see next chapter). CheckAllFunctions: Values 0 (false) and -1 (true): If set to true, also data checks for functions are executed (see next chapter).
- CheckAllTables: Values 0 (false) and -1 (true): If set to true, also data checks for internal tables are executed (see next chapter).
It is also possible to install a server plugin multiple times with different properties set, to switch between them in PM.Designer later on. The PMDesigner.Server must be restarted that the changes take effect. After the server plugin has been installed, it must be activated in those product workspaces where it should be active. In the product workspace properties in PM.Designer on tab “Server plugins” a checkbox must be enabled to activate the server plugin for that product workspace:
Checks
Where a rule states “all languages” the meaning is “all languages defined in plugin property Languages”, see previous chapter.
Product module
- Identifier may not contain special characters.
- Identifier needs to start with a letter.
- Identifier (all languages) may not exceed the length of 50 characters.
- Relations of product modules of class HistoryRoot:
- Identifier from one such relation needs to end with suffix “_Old”.
- Identifier from other such relation needs to end with suffix “_New”
- Product modules need to own exactly two relations to related objects, i.e. the product module that is the target of “_Old” and “_New” must be the same.
- Relations of other product modules: o Identifier may not exceed the length of 50 characters.
- Product modules may only own exactly one relation to related objects.
- Cardinality may not exceed 999.
- Class attributes: o Data types “multilanguage string“ and “boolean” are not supported.
- Identifier may not contain special characters.
- Identifier needs to start with a letter.
- Identifier may not exceed the length of 30 characters.
- Value (data type string) may not exceed 128 characters.
- Class attribute Shortname: o Data type needs to be “multilanguage string“.
- Value (all languages) may not be empty. Value (all languages) may not contain special characters.
- Value (all languages) may not exceed the length of 16 characters.
- Value (all languages) needs to be uppercase.
- Class attribute Longname:
- Data type needs to be “multilanguage string“.
- Value (all languages) may not be empty.
- Value (all languages) may not exceed the length of 50 characters.
- Class attribute RefModel_Suffix:
- Value may not be empty.
- Object attributes:
- Data types “multilanguage string“ and “boolean” are not supported.
- Identifier may not contain special characters.
- Identifier needs to start with a letter.
- Identifier may not exceed the length of 128 characters. o Value (data type string) may not exceed 32 characters. o If value has restriction “by enumeration, selected values”: Value (data type string) may not exceed the length of 32 characters.
- If value has restriction “by table, selected values”: Value (data type string) for columns used as value provider by object attributes may not exceed the length of 32 characters.
- Methods: o Identifier may not contain special characters.
- Identifier needs to start with a letter.
- Identifier may not exceed the length of 50 characters.
Structure Folder
Identifier (of base folders and product module folders) may not exceed the length of 50 characters.
Function
These checks are only executed, if the property CheckAllFunctions is set to -1 in the server plugin installation in PMDesignerServerMonitor.msc (see chapter 2). Then these checks are executed for any function, no matter if they are used by methods or object attributes (as CAIMAN does it), because of technical reasons.
- Identifier (all languages) may not exceed the length of 128 characters.
- Variable identifiers may not exceed the length of 50 characters. (only, if a value is assigned to a variable)
Array
These checks are only executed, if the property CheckAllArrays is set to -1 in the server plugin installation in PMDesignerServerMonitor.msc (see chapter 2). Then these checks are executed for any array, no matter if they are used by object attributes (as CAIMAN does it), because of technical reasons.
- Identifier (all languages) may not exceed the length of 128 characters.
- Dimension may not exceed 3.
- Number of elements per dimension may not exceed 9.999.999.999.
- Element values may not exceed the length of 128 characters.
Enumeration
These checks are only executed, if the property CheckAllEnums is set to -1 in the server plugin installation in PMDesignerServerMonitor.msc (see chapter 2). Then these checks are executed for any enumeration, no matter if they are used by object attributes (as CAIMAN does it), because of technical reasons.
- Value Identifier (all languages) may not exceed the length of 128 characters.
Internal table
Checks for tables whose identifier starts with either “INTAB_EXP_”, “MVA_INTAB_EXP_” or “INTAB_INTAB_EXP_”:
- Data type “multilanguage string” for columns is not supported. These checks are only executed, if the property CheckAllTables is set to -1 in the server plugin installation in PMDesignerServerMonitor.msc (see chapter 2). Then these checks are executed for any internal table, no matter if they are used by object attributes (as CAIMAN does it), because of technical reasons.
- First column needs to be entitled as “key”, second column as “shortname” and third column as “longname”.
- Columns “shortname” and “longname” need to be of data type “multilanguage string”.
- “key”-value needs to be case insensitive unique within a given internal table.
- “key”-value may not exceed the length of 10 characters.
- “foreignkey”-value may not exceed the length of 10 characters.
- Number of rows may not exceed 9.999.999.999.
- Value (all languages) may not exceed the length of 128 characters.
- Value (all languages) may not be empty.
One click deployment
During product data import within the designtime phase not only the product data customizing is created within the msg.PM Connection storage but also the binary data required by the PM.Runtime is additionally stored as part of the “One Click Deployment” functionality. There is no need to supply the PM.Runtime explicitly with such binary data because the runtime is now able to fetch any such required data from the msg.PM Connection during runtime requests when needed.
This lessens the amount of administrative tasks required for the deployment of products because there is no need to take care of distributing such binary data within the system landscape for the individual runtime instances.
Additionally as part of the “One Click Deployment” functionality PM.Designer is capable of defining and administrate a pool directory for export objects. Product data development which is intended for deployment is released into this pool during the export. This means the export binary file itself and its associated additional binary files are stored within in the pool directory. The msg.PM Connection import dialogue offers the available released exports of the pool directory for deployment by the product data import.
Therefore there is no need to handle the binary files of the export directly or performing the product data import by using the CAIMAN software component via command shell anymore, which usually required operating system access rights and solid command shell knowledge.
PSV Import
The next stage of the deployment process is the PSV import. In this step the final compilate file or in best case you are using multiple smaller compilates will be uploaded to FS-PM into some staging area tables.
Hints:
- Ensure you have cleaned up any older uploads with errors
- Ensure you are not uploading from a WAN network. Upload it from your local PC or a fast local network drive.
- It is better to hanle smaller compilates instead of huge files. Maximum size shall not exceed 60 MB
To optimize this process also from a latest patch level please implement note 2270289 and the CAIMAN 34101.49 Patch.
Please implement note 2293150 to have a test program for evaluation of transfer speed
Optimize the PSV import by deactivation of tracing.
Deactivate the RFC trace function: To optimize the runtime it is recommended to deactivate the RFC trace flag in the used RFC connection of the FS-PM system. (SM59 -> find the used CAIMAN RFC destination ->
Deactiavte the CAIMAN RFC trace level: In the file sapnwrfc there are some settings. Ensure the RFC_TRACE = 0 is set here.
Example
#DEFAULT
#RFC_TRACE=3 <<<<<<<
DEST=W*** <<< replace this with your server name
GWHOST=msas***** <<<< your gateway host
GWSERV=sapgw00 <<<< your gateway server
PROGRAM_ID=CAIMAN <<< executable
In addition we recommend to implement the following notes
2157329
2202529
2202580
2216809
2228824
2231927
2232635
2234128
2237557
And the change the system paramaters to the corresponding value
rdisp/scheduler/prio_high/max_runtime 7200
ztta/roll_extension_dia 8000000000
Mass Import
Mass Import is the last step of the deployment process. Also here in worst case and if all quality insurance activities fails some error can stop the whole deployment process and a restart from the beginning is needed.
In this step the content from the staging tables of the previous step will be read and merged with the current IFBC configuration. Because IFBC contain in addition field selection values for attributes msg.PM is not able to deliver, a sophisticated algorithm is trying to set this settings with a best guess logic.
Details can be found in the blog IFBC and the Characterstic Attributes
Spent some time in the detail of IFBC and log to understand how the mass import will work.
Performance optimization in calculation FS-PM using msg.PM
As soon as you have imported all needed data from the product engine, the first test runs can be done. For such purposes there is a trace capability available to write a details request&result log of the interface between FS-PM and msg.PM.
This log has the following behavior
- will write a detailed log
- can be activated per user
- will decrease the performance
To ensure a smooth execution please be aware to follow theses rules
- Ensure the file system where you write the log has enough free discspace
- Activate it only for testing users with SAP user parameter /PM0/3FR_DEBUG on value X
- For background user set the parameter on value SPACE
msg.PM compilate and FS-QUO Quotation
If you are using a classic msg.PM compilate in compination with FS-QUO the standard behavior is a single compilate file including all internal tables. If you have followed the optimization to use an external DB to manage your external tables, most DBs are supported. In the special case of using the file format SQLlite, there is a special side conditions.
TomatosX is only able to handle a single SQllite file per external table
The JAVA runtime of the msg.PM is only able to handle one huge SQLlite file containing alle external tables inside
This makes it very important to handle it in the correct matter.
If you want to use the FS-QUO quotation system, please update the tool PMTExtTableExport to release 3.4.10.1. This release will offer you a new parameter
With the new parameter /SingleTgtSQLite all external tables can be migrated into one single SQLite file.
Export all tables:
PMTExtTableExportU.exe /Compilate=d:\temp\XBOL1000.T10 /ExportDir=d:\temp\SQLiteSingle /AllTables /SingleTgtSQLite=SQLiteAllExTables.db
Update a subset of tables:
Instead of parameter /AllTables the parameter /TableIDFile= can be used too.
The single SQLite file can be used by PQM as external database. It should be configured in the same way like MS SQL, Oracle or DB2 databases.
If you have already exported all tables in several SQLlite files and you need to merge them into one single huge file you can use a new parameter.
With the new parameter /SQLiteDir all external tables existing in the specified path can be migrated into one single SQLite file.
All tables merged from source directory into one file without compilate file.
PMTExtTableExportU.exe /SQLiteDir=d:\temp\SQLiteFiles /ExportDir=d:\temp\SQLiteSingle /AllTables /SingleTgtSQLite=SQLiteAllExTables.db
Using the parameter /TableIDFile instead of /Alltables only the named tbales in the file will be read and merged/updated in the single SQLlite file.
Implementation support:
For SAP related questions contact SAP on the available support channels.
Consulting support for msg related products please contact support-msgpm@msg-systems.com
- SAP Managed Tags:
1 Comment