The golden rules for a successful msg.PM deployment process to FS-PM
Within the deployment process of new products between msg.PM designer and the policy management system SAP FS-PM it is necessary to follow some basic organizational rules to reduce the number of iterations generated by wrong product design, error in naming conventions or mapping issues.
The result of the msg.PM designer is a compilate file. This file will be checked by a tool called CAIMAN and finally imported in the FS-PM system.
As soon as an error occurs, the whole deployment process must be restarted. In worst case it leads to a delay in overall process chain.
Now follow these basic rules:
1. Keep the size small
Instead of extremely huge compilate files use instead multiple compilates by splitting up logical units.
This will help you in case of an error where to find the issue in the designer.
2. Keep the size much more smaller
Using internal tables (rating tables) is a tremendous help in maintenance. But it also leads to a bigger complate file. As early as possible try to use external tables and separate rating content and calculation logic.
3. Devide and Conquer: Landscape
There are several possibilities to setup a multi server msg.PM landscape. Before start installing hindreds of development server, think about what is your goal. In every known case an insurance company is working with different Line of businesses. So here you have your first divider found.
Setup 1 server for the pure deployment process. This server has nothing to do as syncing teh content and sending to the FS-PM system in the xport process.
For every line of business (LoB) setup a unique own development servers (1-n) responsible for one LoB, if it reachs a critical size.
It makes no sense to setup a server if you have only 1-5 product in this LoB. Use your mind to drive this decision.
But in all cases follow the rule #1 and keep your products unique in one compilate file.
4. Divide the responsibilites
Instead of having one huge developer group responsible for everything, split them up by LoB and make them responsible for their server and the E2E process.
5. Install the right hardware
If you alread know at the beginning of the implementation project what will be the final stage of the prodcut design then ensure you directly setup a landscape that is able to handle the data volume and database access in all cases. We strictly recommend to install the msg.PM Designer 64bit version or the successor msg.PM Quattro.
Also ensure the server behinde the designer has enough RAM and CPU and the DB connection is fast enough. If MS SQL Server is too slow don't hestiate to replace the DB of course with SAP HANA.
The following FAQs focus on correct usage of msg.PM designer.
We strictly recommend to get a training before you use the tool and got lost in complexity.
(1) Is there a system mechanism in msg.PM designer to force the developer gives "task id" when they check out the object
In PM.Designer exists the functionality, that a developer is forced to provide a comment (task-id) when saving any object.
This functionality must be activated by each user in PM.Designer under “View/Settings”, section “General/Save”.
With this function activated no user is able to save an object without comment (task-id).
(2) There is no authorization control about who could change what. The objects in basis library which have impact to architecture / a lots of other objects can be changed by any developers. msg.PM designer should provide authorization functionality by library or satellite .
In PM.Designer supports already user authorization on the level of libraries and folders.
See document PMSecurity_34.pdf, section '5.1 Protected Objects'.
(3) There is no process with system mechanism to enforce a traceability of objects which are changes. Every user could checkout and check in without leave any trace. Pre-defined user in each development team could perform the check in activity.
The statement “Every user could checkout and check in without leave any trace” is not correct.
Any check-in operation is traced and can be seen in the history of an object.
Actually the functionality “check-in” is part of the “write” permission to the master workspace.
A separation of this right into “check-in” and “write” may be possible.
(4) There is no system mechanism to identify whether the external tables are changed. In order to ensure that all changes for external table are exported, all external tables are exported every time.
The next release 3.4.12 is offering a bunch of new capabilities. Watch out the release notes.
(5) Currently all products are deployed by every deployment. It increases error quote and runtime
This is not a bug - this is the feature. msg.PM main principle is having all in one file (compilate) to make the transport across systems easier.
For large setups we strictly recommend following the golden rules and use multi-ompilates.
(6) I need urgent help using msg.PM designer, deployment process and guidance how to setup.
In this case do never hesitate to conact the xperts under (firstname.lastname@example.org or +49 371 67403 6633) and involve them at en early stage.
Any issues found in a late stage will need additional efforts to solve,