Walk the correct development path in SAP PPM22/05/2015
Would it not be nice that an ABAP developer in each system can start immediately? The data model is the same everywhere and that the developer knows immediately which areas he / she must go to, to make the necessary changes? Unfortunately this is not the case, for example, just look at SAP CRM, where the data model is quite different from the traditional SAP system. Also in SAP Portfolio and Project Management (PPM), there is a different data model and design concept. This blog is intended for developers who have no experience with SAP PPM to provide them with an overall picture of the design concept and the possibilities of SAP PPM.
PPM is part of SAP PLM (Product Lifecycle Management) suite and can be divided into the following areas:
• Resource and Portfolio Management (RPM)
• Project Management (cProjects or DPR).
In the code of the standard PPM solution can also be seen a sharp distinction in these two sub-areas. For this reason, in this article also a distinction between the two functional areas.
The PPM user interface was developed in Web Dynpro ABAP. For RPM applies that the development is done in conjunction with the Floor Plan Manager (FPM). The screens in RPM-based role can be configured with the configurator in Launchpad transaction LPD_CUST.
A major problem for inexperienced developers PPM is the lack of knowledge of the PPM standard data model. This makes it very difficult at first to find your way within PPM. It is particularly tricky because PPM uses generic GUID key fields, making it very difficult to make the link between different tables.
A big advantage is the generic design model of PPM standard. The standard solution is completely object-oriented (OO) developed, and uses generic service classes.
For this class RPM / RPM / CL_SERVICES and DPR class CL_DPR_API_CORE_SERVICE_MNGR. For both classes apply that, depending on the context of the object, the relevant API class is determined. This takes place in / RPM / CL_OBJECT_API => GET_OBJECT_API_CLASS respectively CL_DPR_API_FACTORY => SET_API_PROVIDER_CLASSNAME. The service classes include, among others, the generic methods QUERY, RETRIEVE, and do_action UPDATE.
Throughout the OO concept and the generic design it is almost always possible to use the standard available classes in custom development and there is no need of using the SELECT statements.
Standard PPM features a wide range of configuration options to implement additional customer requirements. Since a lot of customers have the desire to add custom fields and / or screens to the standard solution, therefor will this document explain the broadly steps that are to be followed in order to achieve this.
It is noted that it is very important to allow communication of the customization screen and standard PPM PPM according to the standard PPM concept.
In this way, the standard flow logic of PPM automatically provides the proper handling of the data.