I have recently had the opportunity to be on a team that delivered EHSM 2.0 and upgraded to 3.0 both on ramp-up.
Being such a new product I wanted to share my experience from a development perspective, hopefully providing some assistance to others embarking on a similar adventure. This first blog aims to give an overview of the solution with the intention of helping to put it all into perspective. The solution is quite well architected but it can be complex to navigate when trying to add custom requirements. I found that once I had a good grasp on how things worked over-all it was much easier to know where to look and start enhancing to achieve the desired result. In subsequent posts I would like to elaborate on the approaches to take when enhancing particular components of the solution.
EHSM is a new solution, extending the original EHS module and has been built from the ground up using the latest and greatest of SAP’s NetWeaver ABAP infrastructure offerings. For more detail on the overall solution you can look at online help in the SAP Library – Component Extension for SAP Environment, Health, and Safety Management
The diagram below provides a conceptual overview of the technical solution. The following sections will go through each of the components and the approaches for enhancing them at a high level:
- User Interface
EHSM has two main access channels Web Dynpro and Adobe Forms. To find all of the objects check out the package EHHSS_PC_INC_RECORDING.
Web Dynpro FPM
FPM is all the rage these days and for good reason, however, when built on top of a domain model such as BOPF it really comes into its own. ESHM leverages this well and most of the generic FPM UIBBs such as forms, lists, tabbed and search components are built on top of BOPF (using EHSM frameworks with FBI [FPM BOPF Integration] ). This exposes the BOPF data layer as well as events, relationships and even UI logic. FPM wires are used to enable generic and configurable connections between components and of course feeder classes are used to provide UI specific behaviour.
- Adobe Forms
SAP Interactive Forms by Adobe are used for offline data entry and can be submitted via email. This provides a lot of flexibility especially for scenarios where the recording of data may be remote and difficult to access the network (e.g. for use by contractors who may not have access to the system). Each form is generated by a ‘data provider’ class which pre-populates fields and drop-downs. The inbound form is handled by an ‘inbound persister’ class that collects the data and orchestrates the mapping and saving of the data. A nice feature is that these classes are not set as final and the implementation class is specified in configuration allowing for straight-forward enhancement.
Although access via mobile device was not in scope for our project I did notice an iPhone app in the app store for this and there is also a web service layer available for integrating third party solutions of such a nature.
- EHSM Tools and Configuration
The EHSM solution provides a large suite of domain specific logic in reusable classes, in particular a gateway layer providing accesses to the BOPF configuration and transaction layer. This provides much of the interaction and logic between the user interface layer and the BOPF transactional layer. Other tools include range of helper classes to assist in working with various EHSM concepts. One such example is the EHSM Party which can represent an HR Person, a System User or Business Partner, etc. (refer to class CL_EHFND_PARTY_PROXY). This model (much of it residing in package EHFND_REUSE_COMPS) is quite rich and well worth leveraging where possible. There is even a master data customising generator (transaction EHFND_CUST_GENERATOR) that can generate objects such as master data tables, text tables and search helps for new data types.
The BOPF layer provides the core business logic and most of the business rules and behaviour is found here. Each logical component is defined as an object so for example an incident is represented in the node EHHSS_INCIDENT. Objects can have usage dependencies with each other and also have inheritance. Actions relating to incidents for example are represented with EHHSS_INCIDENT_ACTION which inherit from EHFND_ACTION and are linked to the EHHSS_INCIDENT object via a relationship definition in the BOPF configuration definition.
Within an object there are nodes that have data and behaviour configured against them. The nodes relate to each other in a hierarchical manner with a root node at the base of the tree. Data is assigned as either persistent (saved to the database) or transient (represented at runtime only) and this is defined by a grouping of data dictionary structures and one table per node where the data for that node is persisted. The BOPF Model and BOPF runtime manage the data structures, relationships and events at runtime. The transaction layer manages the persistence and buffering of the data. The data structures of the nodes can be extended to allow for custom enhancements. Each node also has actions, determinations and relationships (among other things) assigned to it. Actions as the name suggest allow callable behaviour to be executed on the node. A Determination has behaviour that is triggered on particular events in the BOPF event loop. This is where transient field values are calculated and field control occurs.
Even workflows themselves are represented using business objects from the BOPF. In this way each process is encapsulated in the same framework as the other components of the solution. The business objects are called Process Control Business Objects (PCBOs).
Overview of Enhancement:
The two fundamental technologies used are BOPF and FPM. So for the scope of this blog I will briefly mention the approaches for enhancing these and as stated earlier, will go into detail on how to implement specific scenarios in subsequent blogs.
The most common and straight forward enhancement is the addition of custom fields. This is done through extending the standard structures in the BOPF.
The BOPF Enhancement Workbench transaction [BOPF_EWB] allows custom extension to the BOPF objects. Although not everything is configurable, much of the functionality can be extended, including the addition of determinations (useful for adding logic to custom transient fields), actions, queries and even new nodes. The addition of new nodes are especially helpful when adding a new section of data and behaviour to the solution. For example, the addition of a new tab on the user interface. Further information can be found in the BOPF enhancement Workbench document (refer to note 1457235). Another option for enhancement is to use the enhancement framework on the implementation classes for the existing BOPF framework events.
Above I have tried to be as factual and objective as possible, in this section I will taint this article with my own views from my experience so far.
There were many times when my colleagues would find me beaming with the warm satisfaction that an enterprise geek would find in quickly constructing a robust transactional solution to a business requirement. The framework provided a convenient and logical approach to extending the functionality (most of the time). Overall I enjoyed working with the solution.
It was a rare opportunity to be involved in an implementation followed directly by an upgrade. And all the enhancements (from FPM component configuration, to BOPF, to methods) held up considerably well.
The combination of the solution from SAP, and what we were able to enhance, created one of the most user friendly SAP solutions I’ve seen of this nature.
Being on ramp-up was also a good experience and I have to complement the SAP solution team for a well developed product and the great support for us while delivering it.
There were many other times when my colleagues found me shaking my fist at the screen shouting (in a workplace sensitive way of course) “curse you BOPF”. The framework is complicated and this means that things were quite a challenge at times. In particular BOPF and FPM events and relationships (both within and between the two) were particularly hard to piece together, especially at the start of the project.
At times the Field Control configuration was very hard to work with. When it worked it was great but when it didn’t it was very hard to determine why and where the issue arose.
The key to designing and building an enhancement in this solution smoothly is to have a good grasp on the technology components and how they are linked together (both technically and architecturally). Due to these things being relatively new it is hard to draw from experience, which is why I decided to share what I could. As we have gone over the components of the EHSM solution and general approaches on how to enhance it I hope you now have a good place to start as you work with it yourself. I would be keen to hear about your experiences and thoughts on this topic as well.
This is just an overview and if I get the feedback and the time I hope to explore some of the concepts further.