This article continues the series A business case for integrating SAP BI and XI. I will assume you have read the...
business case before reading the solution approaches.
The solution we'll discuss here is based on SAP NW 2004S. Most middleware tools like Tibco have already come up with the ETL as one of the message layers. For more information, visit the Tibco Web site.
Let's take a look at how we leverage the same solution using the SAP XI+BI dual stack on single instance of SAP WAS NW 2004S.
Solution Approach 1: (SAP dual stack XI+BI) + (SAP Standalone BI)
In this approach, we use the ETL layer of the SAP XI+BI dual stack for pushing the full employee data load and we tap an ABAP proxy for sending employee delta records to the business partners. We'll use standalone SAP BI with cleansed records that are apt for business analysis.
The solution approach is two-fold. It involves:
- Sending delta employee records
- Sending up-to-date employee records and searching employee information
Sending delta employee records
SAP XI extracts the employee information from SAP, Oracle and the other four legacy systems using the relevant adapters that then send it to the business partners and standalone SAP BI simultaneously. Users are alerted to any errors as required by the business.
In addition to sending the data, SAP XI can validate and transform the data as required by the target system.
SAP XI pulls the employee data from SAP, Oracle and the four legacy systems through an ABAP proxy and file adapter respectively. Data is zipped as a password-protected email with password protected and sent to the business partners by SAP XI using an email adapter. Data is also transformed into the format required by SAP BI and sent using an ABAP proxy or SOAP adapter.
Send complete dump and search employee information
As we mentioned in part 1, on an ad hoc basis, any of the three business partners can request the complete employee info. In our solution, we accomplish this through an ABAP WebDynpro user interface that takes the request and pulls the file for them. We use the ETL layer of SAP XI to pull the complete employee dump and then we use a file adapter to push the complete employee dump (in groups of records) to the business partners.
The IS team can also search the employee information using the same ABAP WebDynpro that pulls the relevant employee information from the Oracle, four legacy systems and SAP.
After successfully sending the data, we delete the data from PSA tables of SAP XI+BI dual stack.
Solution approach advantages and disadvantages
- This solution is completely automated and doesn't require any manual intervention, which improves efficiency of the IS team.
- Redundant data that is not used for business reporting is not stored in the SAP BI.
- Standalone BI is shielded from the regular ETL process (as it is done by SAP dual stack XI + BI and sends it to SAP BI) that directly improves the performance of the BI, which is predominantly used for huge historical data analytics.
- Robust error handling can be done in SAP XI for alerting the required support group if any error occurs while loading the data or dumping the delta files.
- Files can be archived for re-processing when an error occurs during the data load or when pushing the relevant files.
- The approach enables the IS team to make business decisions by storing only relevant information in BI and not simply dumping the files in the same format as received by the source systems.
- The solution is adaptable for if more systems have to be plugged in with this architecture in the future.
- The business can be better notified of system failures, enabling quicker action.
- Building cross-component applications on top of SAP XI using SAP CAF would take only a matter of hours.
- POC has to be built and tested for feasibility.
Solution approach assumptions
- Complete employee information dump is not requested only on ad hoc basis.
- The volume of the delta and complete employee information is not huge.
- The employee information complete dump file is pushed only to the business partner that requested.
- There are not too many fields that are to be picked up additionally for standalone SAP BI reporting.
- We don't require any additional information beyond the current GED functionality.
- SAP, Oracle and four legacy systems are responsible for the data integrity.
- BI will hold only the necessary fields used for analytical reporting.
This is strictly a solution for the given business case and probably has to be tested for high volume data, as SAP XI has to be highly available for these kind of scenarios. We just have tried to demonstrate an example business case wherein we need to fit SAP XI and use the ETL layer of SAP XI in a BI landscape. Note that the solution approach should be based on various business factors and evaluated for feasibility.
Thanks for reading!
This content is reposted from the SAP Developer Network.
Copyright 2006, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.