Working in an SAP production environment with OWB
By Jean-Pierre Dijcks-Oracle on Aug 07, 2008
SAP is a bit different... it is more structured than most other environments and there are specific requirements on running ABAP programs in production systems. Since this is a common topic, and since we have a very nice solution (if I may say so) for it in OWB, I figured to write it up on blog.
Some background, OWB comes with an SAP connector, and has done so for its entire life. We have invested quite a bit of time, effort and knowledge into this capability. Not just from our development staff, but also leveraging SAP expertise from New Frontiers (www.newfrontiers.com). Active users have worked on the connector to make sure it addresses things like the above described need of managing ABAP code in SAP (more later in detail of course). New Frontiers actually created an entire data warehouse out of the box based on the Oracle stack with OWB as the tool to create all ETL from SAP into Oracle and using OWB to model the entire dimensional model. More on that is here.
So what is the problem? In general, you cannot move some custom ABAP into an SAP production system without the SAP administrator actually moving it. So since OWB deploys into the system, that would not be acceptable as the program gets "injected" from the outside. OWB generated ABAP therefore must play within the rules.
Here is how this works in a real environment:
In the development environment you create your SAP location, and deploy the mappings. The system is open, so you run this directly from OWB. Not a problem. Now to move anything into the QA and Production systems, you cannot use the OWB deploy of a mapping (which will go into the SAP app and throw in a custom document - no SAP admin likes this).
QA / Production:
Once you have deployed the actual program into the DEV environment, you will have the SAP admin transfer (that is an SAP term with an SAP application screen) the program to the QA or Production system. While he/she transfers the program, variables can be changes like the data file location etc. These are specifically set up as variables (I forget the actual SAP name for a variable) in our generated ABAP for this purpose. Now the program is correctly loaded and moved without other modifications into the SAP application.
Some customers now want this executed from within SAP, some do still want this executed from within OWB. In the latter case you create a location pointing to the actual SAP production system, and in that location you tell us to use a function module Z_blabla. This function module is custom and we have example code for this. You also tell us in configuration that you do not want to deploy, but just want to execute the ABAP. Now OWB skips deployment (the actual Report is already there) and just executes the transported ABAP from its new location. The data file is generated, OWB will FTP the file and load it.