When you hear the term “mashups,” what probably comes to mind are Internet applications that combine functionality from different sources. For all you world travelers, imagine that your online photo application is combined with mapping functionality to map your photos to where you took them. That’s mashups in action.
Now, the next wave of mashups has started to infiltrate businesses, bringing this type of innovation to the applications running your enterprise processes. This functionality is delivered through composite applications, and businesses are increasingly using these applications to support a new level of flexibility and to create and customize their processes in efficient, innovative ways.
Using composite applications in your SAP environment can help you quickly meet business needs as well as customer requirements. These applications bring functionality from different sources together into a new custom application to provide a single point of entry for users, which can save your business users considerable time in their daily work.
From my experience implementing these types of applications, I’ve found that they not only make IT more responsive to business needs, but they also help improve the process efficiency of your employees and provide your customers with better (online) services. This article spells out some lessons learned while implementing composite applications in a portal environment — and a great example of a project that adopts enterprise service-oriented architecture (enterprise SOA) business rules.
Composite Applications in a Real-World Portal Project
I recently had a hand in implementing several composite applications at a large Belgium energy
supplier. This company delivers application functionality (SAP and non-SAP) to its own employees (internal call centers), partners (external call centers), and customers. Its core business processes run with SAP technology: Customer service is served by SAP Customer Relationship Management (SAP CRM) and billing is handled by SAP Utilities.
Before the composite application implementation, the call center agents were working with three different solutions: Two were BSP applications (based on Business Server Pages, a predecessor of Web Dynpro) within SAP CRM that the company used to keep track of all customer contacts and to register offers and contracts. The third was an offline application that external call centers used mainly to register campaigns. This application worked on a download of the SAP CRM database. On a frequent basis, this download was uploaded back to SAP CRM to synchronize the data.
While the three applications provided similar functionality to the composite applications that would replace them, they each had separate application logic. This meant that for any functional changes, you would have to build separate updates in all three applications. You can imagine how this affects your maintenance work. The offline call center application resulted in disparities in customer status; until the data was uploaded back to the SAP system, it was not clear whether the customer had accepted a campaign offer or not.
With a keen eye on the future of the business, the company strongly wanted to work on real SAP data via an online connection — actual SAP data in real time to eliminate the offline scenario and use an online connection to deliver the functionality to partners that could not use the company’s network. This led to projects where composite applications and SAP NetWeaver Portal played central roles because the applications’ data and functionality were to be delivered to the end users via a portal.
Three New Portal Applications
The energy supplier decided to create three different composite applications that the company’s internal call center agents (or front office agents), external call center agents (partners), and even customers could use.
The project would serve these three target audiences with the same functional components, but each target audience would see a different user interface, as front office agents require more functions than customers do. Customers and partners would access the portal applications via the company’s Web site, which was built on the SAP NetWeaver Portal platform. The three new applications were:
- Tools: Employees, partners, and customers use this application to calculate the optimal rate category and appropriate contract type for customers based on parameters such as region, season, and yearly consumption figures.
- E-services: This application brings customers consumption-monitoring functionality. Customers enter meter readings, and then the application automatically calculates their energy usage. As an additional service, the application offers the customers advice on the contract type based on the consumption amount and rate category. If customers accept the proposal, the contract updates automatically. To create these services, we combined SAP CRM and SAP Utilities with custom-made functionality to calculate the best monthly budget billing amount.
- Front Office Automation (FOA): This application gives call centers the functionality to support offers and contracts in the portal solution. From here, employees and partners (e.g., front office agents and external call center agents) can create and search business partner contacts and register energy offers and contracts.
The primary goals for these composite applications were to:
- Integrate SAP CRM functionality with SAP Utilities functionality.
- Deliver functionality to multiple user groups: customers, front office agents (employees), and external call centers (partners).
- Use SAP solutions for all required functionality, unless a proof of concept shows that a non-SAP solution is needed to fulfill any specific requirements.
- Reuse existing functionality, such as some of the offer and contract registration functionality that was already developed within SAP CRM for the former BSP solutions.
Portal Architecture Based on Enterprise SOA
With reuse of existing functionality in mind, the solution architecture was based on the concept of composite applications. The portal’s applications use the same core components in the Application and Data layers for functionality, but differ in the Presentation layer by delivering more or less functionality to the end users.
In building the portal solution, my consulting team strictly followed the five-layer approach, which is the starting point for the adoption of enterprise SOA. All the layers have their own specific goals and functionality:
- Presentation: user friendly, easily accessible, quick response, self-service
- Process: operation control, end-to-end monitoring, flexible process optimization
- Integration: middleware, service provisioning, data exchange, enterprise data model
- Application: business transactions, integrity, performance and availability, subprocesses
- Data: data storage, access management, security, integrity
For this type of approach to be successful, the functionality at each level must stay distinct and avoid overlap. This division of architecture creates flexibility among the Presentation, Process, and Integration layers and keeps the Application and Database layers stable. As a result, maintenance time and cost will decrease because functionality is available only in one place and will be reused in several scenarios.
|The portal application’s solution architecture
Why SOA Means More Responsive Business Processes
With this multilayer architecture, your IT team can change one layer without affecting the others. You can implement a new Integration layer without having to recode in the Application layer, or you can change back-end functionality in the Application layer without creating issues in the Presentation layer.
In the example, the energy supplier could even change the SAP CRM application by upgrading or changing application logic with no noticeable impact on end users, as the presentation logic remains the same. (Of course, when you replace application logic with other logic, or with another system, you still need to adapt the mapping between the Application layer and Integration layer accordingly.)
In the Application layer, SAP CRM and SAP Utilities provide standard and custom-built functionality to meet the requirements for the Tools, FOA, and E-services applications. The Integration layer connects the functionality from the Application layer and provides the functionality to the Presentation layer. In this example, the solution architecture doesn’t include the Process layer, as there is no need (yet) for process management. However, if the company ever wanted to implement a customer process (E-service) that needs approval from the front office, this would occur at this level. The approval workflow gets started in the Process layer, and event management monitors this workflow and guarantees a timely follow-up.
The Integration layer provides the functionality from the back-end systems as Web services. (These services would have previously been RFC-enabled function modules.) The three different target users of the applications use and reuse the functionality delivered by these Web services— each with a different interface, but with exactly the same back-end components. The Integration layer was implemented on the Composition Application Framework (CAF) service layer.
While using this new technology from SAP, at some points, we felt like pioneers in the CAF world. What we discovered, though, is that CAF is a strong concept and methodology from SAP that improves the efficiency of the development process by reusing Web services and modeling the application functionality instead of coding. With CAF, SAP delivers standard templates and code generators that guide you in adopting enterprise SOA rules. In the future, with an increasing amount of integration scenarios or message broker requirements, you can easily replace the CAF service layer with SAP NetWeaver Process Integration (SAP NetWeaver PI, formerly SAP NetWeaver XI).
Taking a Composite Approach
Ultimately, composite applications in a portal solution have delivered some key business benefits. In the example, benefits include:
- Because the solution’s back-end functionality is provided as Web services, it’s easy to reuse existing functionality.
- Multiple user groups can access the same functionality through different interfaces.
- New functionality can be delivered quickly to the business and its customers.
- The solution’s applications are running stable, even at peak levels, with different call centers of 80 concurrent agents running FOA applications.
- Customer service levels have been increased by delivering E-services on the Web site.
- Call center efficiencies are improved by bringing all functionality into a single portal. Agents can help the customers more quickly, and backlogs are reduced.
From my experience with this and other projects, I recommend that SAP customers look at how their portal functionality — or any area where custom applications are heavily in demand — would benefit from the composite application approach. In this case, the conditions were ideal for enterprise SOA architecture and the composite applications and led us to new insights on how to approach such portal projects with an eye for future enhancements.
Some have referred to the hype around composite applications, but on a small scale, you’ve seen that composite applications are here to stay and will help you to quickly follow up on business needs and customer requirements.
7 Lessons Learned
Get buy-in for what may be a new approach. Start with a proof of concept that addresses all of the stakeholders to validate the approach that you want to use — especially if this is the company’s first introduction to enterprise SOA and composite applications.
Check on your current components. Thoroughly analyze all of the back-end components that are to be reused. Their quality will influence the quality of the end product, which will certainly influence your project planning.
Set up your application servers for success. We implemented the CAF service layer on the same Java application server that runs SAP NetWeaver Portal. We recommend that you use a separate application server to handle integration. This will decrease the possibility that integration activities influence the performance of the portal.
Maximize your development environment. Before you use the CAF development environment, make sure you install the necessary patch for SAP NetWeaver Developer Studio. This patch in CAF will allow you to have more than two simultaneous connections to the SAP back end.
Understand your integration needs. If you have multiple integration scenarios, consider SAP NetWeaver PI. With the solution described here, we used the CAF service layer, which is good for low-profile integration scenarios.
Focus on back-end components early. Make sure that the components deliver the functionality the services are requesting so that you don’t run into timing issues when importing Web services or generating applications. Importing and generating is very time consuming in the current CAF release (7.0.12), and you want to prevent importing a changed back-end component again and again.
Build for reuse. If you plan to create new back-end functionality, build it with future reuse in mind. Don’t use back-end components that combine presentation and application logic because they are very difficult to reuse.
|Twan van den Broek is Solution Architect and Managing Consultant at TopForce. His broad experience in SAP development is combined with knowledge on current SAP NetWeaver and enterprise SOA possibilities to deliver the TopForce High Performance Workplace.