Introduction
PBT which is ‘Policy Base Technology’ is the base development framework for FS-PM. It has been woven together with remarkable OOPs concepts along with other components. For an entrant into FS-PM, the world of PBT within the transaction '/PM0/3FW_START' seems cryptic at times. At times the key to understanding and working with it is to have a simplistic view. This blog is an effort in that direction.
Layers
PBT is comprised of various layers. Each layer has its specific purpose and utility. This enables the development to focus on a specific set of tasks within the periphery of each layer. The layered approach is not too different from the usual programming practices in SAP.
DB layer
This is the layer which deals with the transparent tables and their associated actions. The tables are created within the data dictionary. These tables are then introduced as a Persistence Model object. A class called the data access agent is created around this table. This will cater to CRUD and caching functionalities for the concerned table. At runtime this is the class that is instantiated to cater to all operations around the respective table. At this stage the persistence model still represents a more technical representation of the object.
Business Object Layer
Entity model
The persistence model need to begin having a more semantic meaning for its existence. This process begins in its linkage within an Entity model. An Entity may comprise of 1 more Persistence (tables) Models. Within the various process we think and deal with these Entities basically. Most of the times the Entity is comprised on just 1 Persistence model. E.g. Policy holder. However like in the case of Coverage Entity it is comprised of a set of persistence model. This allows storage and management of differential data of coverage based on LOBs along with the common portions.
Business Object
At this stage the system has in its dispensation a set of Defined Entities. However there aren’t related amongst themselves. A business object is crafted which defines these relationships amongst the various entities. A corresponding pure Computer Sciences concept that has resonance here are the ER (entity relationship) Diagrams. This Business object can then be brought alive (instantiated) and consumed during business process. FSPM has predefined set of Business Objects (BO) within the system .The prominent business object of them is the Policy BO. This formation influences both the possibilities and the constraints on the sort of operations that can be done with a Policy itself. For E.g. the Policy holder entity is a child of the root entity of Policy itself. Thus policy holder can be operated upon directly as a child of the Policy entity and not an alternative main axis element. This product engine product models also need be aligned within the available structures of the Policy BO. At runtime the BO instance is to be generally considered the single source of latest data. And so data is usually read to and fro from it. FSPM provides a many central services via the BO model e.g. commit and rollback. Within a business process multiple BO’s can be loaded and worked upon. This is evident when correspondence (which is a BO in itself) is handled during the Policy (Policy BO) processing related business processes. It is not too often that implementation project and customer makes changes in the BO Layer.
Process Layer
The layers discussed have a broad spectrum. They sort of represent the infrastructure and the base. In practical terms we think in terms of specific tasks/processes at hand. Invariable these tasks will have an algorithm or a flowchart at hand. This is where the process layer come into the picture.
Process Model
It is easily the nervous system of the FSPM world with PBT . The algorithm or a flowchart at hand can be translated into the system via this component of PBT. This is for a specific process of interest. This is the portion that stiches all the other components of the PBT world together. Thus all the others components come into play due to the modelling in the process models. An amiable feature is that one can view this logical flow of the process model visually. Such a facility is also available for the other models within PBT. Process Models also allows one to read the minds of the creators of existing process models to some extent. Thus one can get a jumpstart into understanding existing transactions and processes. Thus a process model is a step by step representation of the flow of logic for a particular process. These steps can be core code logic (classes/methods), dialogs, other models, system dialogs, cycles, hierarchy, branching’s etc. PBT doesn’t impose stringent rules on the modelling approach. There are few rules and basic guidelines.
Sub controller Model
This is a component that deals with the organisation of the dialog. It allows the modelling of the look and feel of the screen itself. The dialog/sub controller models can be created and reused in many process model if required. In an MVC construct this component represents the ‘View’. The user can focus totally on the display. The se51 screens are attached within the dialog model. PBT provides for a set of classes which make the programming of the screen related UI elements usage much easier. There are few protocols that need to be followed with regard to the screens usage. For example we do not usually do the classical screen programming within the PBO/PAI modules. A placeholder for such code with in a component called the process context. There is a concept of constraint class that allows a runtime decision of the display or hiding of the respective sub controller node.
Process context
This is a like a bubble around each of the sub controller nodes. They can control the UI related behaviour for the sub controller node it is set for. The control can be in form of data display, data retrieval, Screen properties, reactions to actions etc.
Channel Layer
The channel layer consists of the channel model. This component allows setting up of basic attributes of the fields in the various entities. These attributes could be the default display settings, IFBC relevance, product engine relevance and mapping etc. Along with this it is possible to define and generate other structures that can influence other processes. The channel structure is the equivalent of the screen structure that is used in common ABAP programming. The field modifiers structure will carry the screen attributes. What is evident from this is that the channel model allows definition of the ‘Carriers of information’ of both the data and its attributes.
Conclusion
The onus here has been look into the fundamentals and the broad concepts. There are many more concepts which come into light when investigated deeply. As it was mentioned earlier due to the visual modelling approach with PBT it isn’t too difficult to pick up a process and start digging. Give it a try and soon you will start appreciating its architecture!
