This is Part 2 of 2 dealing with EPM Integration and Financial Information Management. If you have not read Part 1 discussing Installation, please read it first. For me, there are two components to configuration.  First there are systematic configurations to bring the environment up and running.  And then there is usability configuration to setup user & groups (although it’s part of environment configuration...), but most importantly creating and configuring data store connections.

For the environment configuration, it’s rather straight forward with version 10.0.  As for 7.5, you had to configure the server.properties file manually in a text file editor and experiment with some debugging/testing to ensure all the properties and their values were set accordingly.  As for version 10.0, it ships with an admin page (web page) as part of the FIM application.  In the admin page, you can configure in a web form and test each of the properties and their values.  Once all the property values have been tested, simply save and restart the web application server and that’s it.  This reduces a lot of manual testing and bypasses eye tests.

As for the user/group configuration and datastore configuration, I also found it straight forward, but can be tricky in certain situations for complex user/group security setup.  For the easy part, simply log into CMS and create 4 user groups:

• Business Users
• IT Administrators
• Executors
• Auditors

Business Users groups is the group that will ultimately be the person(s) the will create the jobs.  Each job consists of the following core components:

• Source datastore
• Target datastore
• Mapping Tables/definitions

There are other components such as sharing transaction/error tables across multiple jobs, assign user permissions, and etc.  For this blog, creating job details and defining mapping tables to customization will not be part of it as there are a lot of variations that can be built and have potential to expand the details for the blog.  Having said that, I will cover the roles/responsibilities and how does that relate to a FIM job(s).

In FIM, there are 4 distinct group containers that one can create in CMS.

• Business User is the primary group that creates the job and its’ definition.  As stated above, a business user will need to define the source of the datastore and target of the datastore for the job.  The primary component of the job is to define the mapping template from source to target datastore.  All things being equal, business users can be developer(s) and/or pure business user(s).  The purpose is to expose the Data Services in a user friendly environment whereas a user can create ETL job without ever having to know the coding aspect of ETL and integrate data.
• IT administrator is an administrator type user whose main responsibility is to create the datastores and maintain/support FIM.  Creating datastore connections involves establish connections to DB, BW, and EPM applications.
• Executors and auditors groups are pretty much self-explanatory, executors execute jobs and auditors audit the history and data.

For the datastore and the IT administrators, there are few more additional steps.  For the most part, the creation is self-explanatory here as well, i.e. create connections to database with parameters that are native to SQL server, Oracle server, and etc.  Mainly, it requires an IT administrator to work with the underlying application/DB to delegate the privileges on the each of the underlying applications in order for FIM to access it.  This includes things like creating/configuring delegation or importing certificates/trust between NW and BIP as examples.  Each type of connection has default configuration settings that you can find in http://help.sap.com under the section analytics -> enterprise performance management -> Financial Information Management (FIM).

Key Take Away:

Main take away for the configuration of FIM is to always make sure end-to-end testing is performed.  Ensure all components are tested and validated from testing and validating each of the datastore connection(s), creating a sample test job with test mapping, exposing custom jobs, and etc.  Everything may seem and appear as though it’s working, but unless each of the components is validated, there could be potential setback(s).  I would not been able to notice that DS 4.1 had errors if I hadn’t tested it fully.  Also, I’d found another error during installation which was a specific case where BPC was used as a source.  I’ve identified a missing file and although I managed to find a workaround, nonetheless, if such specific test cases were not tested, it would only have prolonged the development and inevitable issue down the road.  This is another point in the blog, Installation vs. Technical Consultant Part 1 that highlights the difference between the “technical consultants vs. installation consultants”. 

Loading Data into BPC NW

Of all the datastore connections, I found myself spending quite bit of time & effort in configuring the BPC (NW) datastore.  This was/is due to the fact that there are essentially two different technologies involved here.  First is the integration with BusinessObjects and second one is the NW stack.  Meaning, there are two separate authentication mechanism where in FIM a user is being authenticated to CMS and BPC is being authenticated to the ABAP login module.  So not only will each user have to be first authenticated by each system, but then proper delegation and trust has to be setup between the two systems.

Well, you might be thinking that it wasn’t too bad, just configure CMS and create a user via SU01.  This is not quite the case (of course!).  There are few important steps in order to integrate both technology stacks.  First you have to ensure that a security certificate is exported and imported from NW and CMS, after then enable the SAP authentication plug-in.  One could actually create an alias and map out users to windows users, but that’s not necessary.  There are step by step instructions on the steps of creating, exporting, and importing certificate on the SAP Wiki site:  Search for “generate keystore and certificate for BI4.0”.  Once the delegation is established, there are few more steps, but should be smooth sailing after that.

The main part of the delegation is to allow user login to be authenticated and generate login token.  Once the login token is created then, in return it assigns SAP assertion token as well that can be used to delegate account via HTTP requests to be used by cookie.  This allows BIP on behalf of the user to communicate with BPC NW.

In summary, I hope I have shed some light on some of the details you may need to be aware of regarding installation, configuration, and integration of EPM applications with BIP that might not be so obvious from just reading the installation guide.  While installation and other guides are readily available to assist one to navigate through the installation, it is just that and they are there to assist the installer/technician for their installation and basic configurations and should not be the end-all/be-all.

In addition, one should not automatically assume everything will be working once installation is completed.  Regardless of whether you have decided to take on the endeavor of installation and configuration or hire profession consultant, always make sure to plan out the tasks prior to installation and spend the extra time/effort to test each and every component of the solution.  This will ensure you don’t face issue(s) that could have been avoided at the beginning.  I know how great it feels to have the solution up and running for the first time, but it can turn out to be fool’s gold so always use precaution.