This was the third student research project offered by Claudius Fischer, a software architect at SAP AG, in cooperation with the HPI. The task he set his students was to develop, model, and implement application scenarios for “order to cash” based on a service-oriented architecture (SOA). In addition to SAP enterprise services, the students used services from a range of other vendors, including Google and Fedex, and combined them using new technologies such as Ruby, Java, and .NET.
A total of four working groups mapped the subprocesses for the scenarios, which – just as in house construction – had to dovetail perfectly. “This was a real challenge, and the students were very creative in solving it,” says Fischer.
The project resulted in four separate solutions: for an online shop, for picking, for processing and checking payment transactions, and for monitoring and analyzing customer-specific data.
Picking 2.0 (2.400 Z)
This software solution is middleware that integrates picking into an existing backend system such as the SAP Business Suite, with graphical user interfaces provided by a Web application and an application for PDAs (personal digital assistants). The solution is equipped with open interfaces for integrating additional applications.
The Web application supplies the store manager with real-time information about the efficiency of the warehouse and the warehouse personnel. It also delivers key performance indicators, such as the number of products processed per hour.
Always reachable on the move
The IT-based picking solution runs on specialized hardware such as robust industrial PDAs. These mini-computers can be operated both in adverse lighting conditions and when wearing gloves. They have built-in barcode scanners for identifying products, and WLAN or GSM modules to ensure unbroken data communication with the middleware system.
At the beginning of his or her shift, the warehouse employee logs on to his/her PDA, which automatically calls up the bill of materials to be processed next and displays the first article. When the product barcode is scanned in, the article is marked as packed in the bill of materials and the next article appears automatically. At the same time, the system confirms the current status of processing. Special, integrated mechanisms protect all the data entered from being lost or damaged if the PDA breaks down.
Central hub: middleware
The middleware forms the core of the picking system. This is the central hub where everything converges, including integration with the existing backend system (the SAP Business Suite, for example). This means that it is possible to change orders or to check on the current status of processing at any time. In addition, data on payment transactions can be linked with picking data if, for example, an analysis of customer behavior is required.
Forwarding agents offer their services via standardized interfaces that are variably interchangeable on the basis of a service-oriented architecture. Delivery costs vary from agent to agent, and depend on the product to be delivered, its weight, and the delivery address. The middleware system helps with decision-making by automatically selecting the cheapest service provider.
At HPI, support for the project was provided by Matthieu-Patrick Schapranow and Jens Krüger – both research assistants and SAP NetWeaver experts at the Institute. They are full of praise for the universal applicability of the SAP modules. “This project has shown that you don’t need comprehensive SAP expertise to build a software solution based on SAP systems,” says Schapranow.
During their research projects, the students are treated like real customers. Via the Enterprise Services Workplace in the SAP Developer Network (SDN), they access the enterprise services in the SAP Business Suite and the latest SAP backend systems. This “playing field”, as Fischer calls it, is used primarily by SAP customers and partners as an introduction to SOA and a way to test prototypes for service-based applications. This means that the students work under the conditions of a real customer project, which is a “unique opportunity for them” during their training at the HPI, says Krüger.
Successful test case at the HPI
For SAP, the student research projects at the HPI are “helpful and very comprehensive test cases,” says Fischer. “They enabled us to close crucial gaps in the interaction between the enterprise services and in the SAP NetWeaver Composition Environment before the SAP products became generally available to customers.”
A further plus point: The results obtained by the students prove that SAP’s enterprise services can be deployed flexibly and on any platform. “Customers do not have to use SAP NetWeaver: They can call up the services over the Internet from any environment and integrate the processes and data from the SAP backend system into their specific applications,” explains Fischer.
“Prefab houses” based on SAP NetWeaver
The HPI students extended the SAP business process modules and used various techniques to merge them into one “building”. Process modeling took place outside the SAP System and each of the four working groups took a different approach to the task. The new version of the SAP NetWeaver Composition Environment will offer new tools for modeling business processes (SAP NetWeaver BPM). These tools make it possible to build “prefab houses” that simplify the transition into the service-oriented world. “Teaming up with the students to provide the necessary proof,” says Fischer, “would be an interesting challenge for a follow-up project with the HPI.”
Ruby is a new-generation programming language that was developed in the mid 1990s by Japanese Yukihiro Matsumoto. It interprets and supports multiple programming paradigms (including object-oriented, procedural, and functional programming, as well as concurrency) and offers dynamic typing, reflection, and automatic memory management.
The open-source Web application framework Ruby on Rails is written in the Ruby language and is based on the principles of “Convention over Configuration” (CoC) and “Don’t Repeat Yourself” (DRY). CoC means that, rather than having to write configuration code, programmers comply with conventions when naming objects so that the objects automatically interact with each other. DRY describes the principle of using parts or all of code that has already been written to avoid having to repeatedly build similar functions from scratch.