Framework Technology Links Applications, Documents, and Processes (Part 1)

The name of SAP Records Management indicates only one aspect of the solution. In fact, it does manage digital documents and structure them with an orientation toward business processes. But SAP Records Management also helps record business processes. After all, files in an SAP solution do not contain only scanned documents or documents edited directly in the SAP solution; they also contain references to documents or other business objects that are created in the context of transactional applications. Such objects include postings in financial accounting, orders, opportunities, and many more.
From the technical viewpoint of IT, these objects are the data records of a database. However, the information contained in a business object, such as a financial accounting documents, is not simply stored in a database record. As a rule, business objects are complex, and the information they contain is distributed across several database tables. Only the use of the SAP solution creates the context. Therefore, SAP Records Management manages not only documents, but also complex data records that complement the information in a file. In SAP terminology, these data records are called “business objects.”

Application Programming and Modeling
Application Programming and Modeling

If all the information – both the documents and the business objects – are collected structurally in a file, the file would document the flow of a business process. Workflow solutions, such as business workflow and records management, complement the information. The workflow solution helps direct and automate business processes. The processes modeled with the workflow solution can access files. And in the reverse direction, processes can be traced and logged from the files. This dual function of managing data and documents and of controlling processes actively is the decisive, competitive advantage of SAP Records Management.

What’s Needed? A Sustainable Infrastructure…

Before development on SAP Records Management began, some basic questions had to be answered. What exactly is the necessary functional scope needed to manage electronic files? What are the contents of those files? How is their content structured and summarized? A dilemma appeared with these questions. Every definition of a specific functional scope or a specific record of objects remained unsatisfactory.
It was impossible to predict which SAP objects would play an important role in records management or which objects in customer projects have to be considered. Accordingly, the first task was to develop a sustainable infrastructure for SAP Records Management – an infrastructure that would link almost any information object to another and then to link them to a uniform software solution.

…and Intuitive Operation

An additional trend also emerged. In a modern application, transactional applications and digitized documents quite properly exist next to each other. Dealing with digitized documents is usually much more intuitive. Processes can be improved, and tasks that users find unnecessary can be automated. For example, users want to fill out familiar forms directly on screen, and they want to write business letters and store them in a file without having to manually transfer the address data in the software solution to the letter. And companies want a workflow solution that can actively pass the corresponding work throughout an organization.
Many of these examples are already available as technical components in various SAP solutions, such as output control and print formatting (Smart Forms) for forms or in business workflow. Accordingly, SAP did not need to redevelop these kinds of elements for SAP Records Management. Naturally, the solution could be a success only if it were able to integrate existing components. These considerations outlined the context for SAP Records Management and gave birth to the idea of the service provider framework.

The Service Provider Framework

Framework Technology
Framework Technology

The term “framework” is often used quite without any precision. Many applications that support some openness to customer modifications or modifications to higher levels of software already use the term “framework” for these abilities. Such techniques – user, customer, or application exits – are also found in SAP solutions as Business Add-Ins (BAdIs). However, the service provider framework encompasses significantly more than a record of published interfaces that can be used for customer-specific modifications.
Consider the following example. The programs for posting an order in SAP Sales & Distribution (SAP SD) and the programs for posting a vendor invoice in SAP Financials (SAP FI) use many of the same elements. These elements include checking for the existence of the company code entered by the user. But the programs exist only for themselves. That means that an SAP SD order per se cannot be related to a vendor document, but that the vendor document, for example, can appear as an explanatory appendix to the order. The tasks are treated differently in electronic file management. With electronic files, a concrete instance of order files must provide concrete visibility of orders, vendor invoices, or digitized documents in a common structure.
Framework technology does more than just help solve integration questions in SAP Records Management. It also helps in other application contexts. For example, it can record disagreements and complaints in the context of financial accounting and document the process of creating quarterly and balance sheet processes.

Joachim Becker