<b>
BW & XI
How to Guide
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/40574601-ec97-2910-3cba-a0fdc10f...
U can connect BW and Xi by proxy .
How to Push Data from BI to XI
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/e698aa90-0201-0010-7982-b49...
How to Push Data from XI to BI
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/18dfe590-0201-0010-6b8b-d21....
</b>
Kindly refer to the following business case for XI & BI dual use
Most of the time when a business asks to use BI open hub architecture and extraction mechanisms instead of SAP XI, it's because of the extra costs and budget involved in using XI. We'll propose potential solution approaches for the business case that leverage SAP XI and open hub architecture and we'll look at extraction mechanisms of SAP BI that do not use SAP XI. We draw out a comparison matrix that concludes the recommended approach.
Business drivers
Let's say that with an organization mission of "Global Business Processes," all of the subsidiaries of Org A plan to replace and merge most of their back office solutions into SAP. IT landscape is the most critical factor; hence, we propose a solution approach, in the form of a Global Employee Database (GED) business case, that can help the business to reap maximum benefits.
Business case description
GED is a legacy system that the subsidiaries of Org A use for storing employee data. The IS team needs to update the data each month after it collects the changed records from the HR and payroll departments. Each subsidiary provides the delta files in either Excel or fixed width formats, which the IS team then reconciles and loads into the GED. The IS team sends these files to three external business partners on a monthly basis. First, it uses export routines for each of the business partners; then the files are password protected, zipped and sent out via email. One partner receives a text file, but the other two receive spreadsheets.
Sometimes the IS team is unable to send the files on time because of problems that might occur in data loading or data reconciliation.
The IS team also sometimes uses GED to search the employee information for internal purposes. GED is also used annually to collate diversity information from all of the businesses as of March 31st. This is to provide an overall company profile for input to the annual report. During this operation, the IS team has to manually pull the data from GED and use lookups and pivot tables to produce the info required (Crystal Reports are not working). On an ad hoc basis, business partners may request a complete dump; in this case, the IS team needs to pull up the employee data from the GED manually and send it to the business partners.
This is the current landscape in the organization:
Drawbacks
1. Manual intervention by the IS team affects the businesses' ability to perform key activities.
2. The approach consumes time and effort by the IS team for collating the employee data, loading the data into the GED and sending to the business partner. It can hamper the IS team's ability to carry out critical day-to-day activities.
3. Manual processes are more error-prone and effort-intrinsic.
4. No mechanism is available to slice and dice across the data to come up with KPI'S.
5. The IS team is unable to monitor and track business across various subsidiaries.
6. After requesting the complete employee information data, business partners have to wait for the IS team to pull the large volume of data and reconcile and send it.
7. No automated mechanism is available to notify in the event of failure of data loading.
8. The process is human-dependent and prone to loss of information when a person leaves the organization.
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:
1. Sending delta employee records
2. 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
1. This solution is completely automated and doesn't require any manual intervention, which improves efficiency of the IS team.
2. Redundant data that is not used for business reporting is not stored in the SAP BI.
3. 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.
4. 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.
5. Files can be archived for re-processing when an error occurs during the data load or when pushing the relevant files.
6. 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.
7. The solution is adaptable for if more systems have to be plugged in with this architecture in the future.
8. The business can be better notified of system failures, enabling quicker action.
9. Building cross-component applications on top of SAP XI using SAP CAF would take only a matter of hours.
Disadvantages
1. POC has to be built and tested for feasibility
Conclusion
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.