To derive user interfaces directly from business logic relations is a hot, lengthily-discussed topic and an old dream of Software Architects and User Interface Designers over the last decade. Many frameworks were built to reach this goal, but most of them failed due to the complexity of the business logic which needed to be implemented. Until now! With the Floorplan Manager (FPM), this dream became reality: generation and configuration of user interfaces has never been as easy as it is today with FPM.
FPM started from the opposite point. Established as a UI framework based on Web Dynpro ABAP, FPM streamlined the appearances of applications in the classic ERP by providing central components for the assembly of the UI parts. These central components served as the skeleton of the applications and were consequently called ‘floorplans’. What FPM had to offer was spiced up ever more with additional components for common UI patterns such as forms, lists, hierarchies, searches and so on. Business logic was encapsulated in feeder classes and thus the idea was somehow obvious to provide generic feeders to consume business object models. The image below is a screenshot of an FPM application generated purely on OData information retrieved from the World Wide Web (WWW) – without any line of UI coding to be written.
But stop! We should go back three steps …
Where do we come from? What are the stages of UI development? A short subjective historical overview is needed:
As I struggle to decide whether I have just started the second half of my life or have already finished the first half, I came into contact with computers and programming with the legendary TI99 – and I am still missing the GOSUB-statement. Later, with Fortran or the much cooler Pascal, we coded everything into one stream of code. Statements as writeln() and readln() were spread all over the code; UI and business logic were completely mixed up together.
When I started at SAP some time ago, we studied ABAP and wrote reports and GUI screens. The Screen Painter was already a step forward; the first time that I came into contact with a graphical design tool where user interfaces were not coded! But the Screen Painter only provided the UI layout; UI logic and business logic were still mixed inside the coding (LEAVE TO SCREEN 100).
Later, Web Dynpro ABAP came into the game with the MVC (model-view controller) architecture and the separation of components and their configuration. It became possible to define components and allow for code-free configuration on top. Actually, it was the SAP HCM development area who delivered the first pre-configured components. And this is the point where FPM enters the game; and now we can continue with what was said before.
FPM exploited the possibilities of UI components and their configurations to a maximum extent. By means of the UI components, common parts of typical applications were defined and feeder interfaces were introduced as communication interfaces between these UIcomponents and the application logic. Application developers implement the feeder interfaces within the feeder classes in which they define the data structures, the data itself, the actions and the event processing. The entire UI definition is separated from the business logic; the UI is defined entirely in configuration, based on the feeder classes which define what can be configured on the UI (fields defined in data structures convert into form elements or table columns, actions convert into buttons or links). This procedure provides a lot of freedom for UI composition. All good and desirable, but what about a generic approach? What if you knew already about the data definition and their relations? What if you could generically access the data without writing feeder classes? What if you could already propose the structure of the application and a first UI? Unrealistic? Hmm, let’s see…
Business object models allow the description of objects and their relations in a well-defined way. Some of them – like BOPF – model the business logic directly on the database tables. Others – like BOL – allow the consumption of legacy business logic which has already been encapsulated in APIs. For completeness, one should mention SPI (Service Provider Infrastructure) which provides an external facing on the UI so that it can be used in the Demilitarized Zone and, last but not least, OData, the Open Data protocol which serves as a web standard to expose any data in the WWW for any consumption based on industry standards like REST, XML, HTTP, Atom and JSON. There are many differences between these object models, but all of them define objects, relations, actions and queries. All of them provide a full and comprehensive encapsulation which serves as a uniform facade for further consumption. So they are generically accessible by a UI framework.
Generic feeders are provided by FPM and by other frameworks to access the data, their relations and their actions. Depending on the relations, the cardinality can be derived and this decides whether a form or a list should be used to display the data (or better still, a form-repeater with a separate details block?). Queries are transformed into a search screen to access the root object. Using the FPM wiring concept, even the dependencies between UIBBs (e.g. adapting content of a details view when changing the selection in a master table) can be pushed to the UI configuration whereas the business logic part of the dependencies (e.g. an association between the nodes) is encapsulated in generic connector classes.
This all works perfectly for BOL (Business Object Layer) and has proven its value in the renovation projects within HCM and FIN development. FPM provides a creation wizard, the ‘Application Creation Tool’ which accesses a certain BOL component and transforms all available nodes into UI Building Blocks (UIBBs) – well, you have a chance to de-select those nodes you do not want to see on your UI and which have no relevance to the application you are going to construct (see image below). These UIBBs are put together into an Overview Page Floorplan (OVP) and are wired according to their relation defined in BOL – and your application can be generated out of the box. You are totally free to adapt this application in FLUID (Flexible UI Designer – the FPM configuration editor). There, you can refine the UI, eliminate unwanted table columns and form elements, add and rearrange fields, columns and buttons or simply change display types if needed, and you can revise the wiring between the UIBBs. So you gain both: an application generated based on the definitions defined in the object modeling layer, and a UI with highly-flexible configurability options. Talk about easy UI creation!
What works for BOL also works for BOPF (Business Object Processing Framework). Since the FPM does not provide generic feeders for BOPF, an intermediate layer has to be used, the so-called BOL-BOPF adapter. This adapter provides a seamless transfer of BOPF model definition to the BOL-based FPM feeders. This allows for a revolutionary end-to-end process. In the Business Object Builder (formerly known as BOPF Enhancement Workbench (see sample image below)) you can define your business logic with all the objects, their relations and their actions. In the next step, you can start the ‘Application Creation Tool’ (mentioned previously) and construct your application with BOL feeders but based on your underlying BOPF scenario.
This approach helps application developers to first invest into the clear analysis of the business process and to separate business logic from the UI entirely. Additionally, with this approach it is possible to start IT projects in complete reverse, compared to how they were started one decade ago. Instead of letting hundreds of UI developers swarm around and build their individual ‘perfect’ islands (which fit together so badly inhomogenously), the first move is with the architects who know and understand the business processes; so they can build and refine the underlying business model. Then, finally, based on this business model, the UI can be created and tailored exactly to the process that customers want to install. These UIs can then be adapted flexibly and enhanced easily by pure UI configuration – but without altering the business model underneath. This will definitely lead to a so-far-unknown and much higher level of business process integrity in modern UIs.
You want more information? See Floorplan
Manager on SCN, e.g. the Administrator’s Guide, the Developer’s Handbook (http://scn.sap.com/docs/DOC-30668 ), the Adaptation Guide (http://scn.sap.com/docs/DOC-28799 ) and many others. – For BOPF, here is the documentation on the Business Object Builder (BOB).
- SAP Managed Tags:
12 Comments
