cancel
Showing results for 
Search instead for 
Did you mean: 

What are best practices with ABAP dataflows and SAP securities?

Former Member
0 Kudos

Hello,

We have several jobs which involve very large volumes of data, which get joined/filtered to a small result (~5mb text file is result, however input tables are many Gb).

Our jobs were initially written as standard DF's pulling the data from the SAP table and then processing in Data Services, but this was too slow. As a result our team has created function modules on the source ECC systems to pre-filter/join the data and send only the result.

This is time intensive and requires a lot more work than having the query/filter logic in DS.

Investigating ABAP Dataflows suggests these are the best way (and appear to be SAP best practice for this situation).

Our security team is concerned with giving the DS SAP user so much access to run "Generate and Execute" permission. As we understand, if this is provided, BODS can automatically convert all query logic within the ABAP Dataflow into an ABAP program, upload to the target system, and then execute the program.  This would be desirable because we have no need for any ABAP developer access and can more easily move between our dev, quality, and production systems.

If they cannot provide this, we are hoping to at least provide the "Execute Preloaded" security but then this will require us to export the DF logic to ABAP, then have another person import it to each landscape or with each update. This is not as good but still "ok."

My question is: what are best practices with SAP security for ABAP data flows? Do people generally give all the user rights for the DS userid on the source system for Generate/Execute? Or is it more common to just allow the Execute Preloaded and then have someone manually add the ABAP program?

Accepted Solutions (1)

Accepted Solutions (1)

former_member187605
Active Contributor

Best practice is to use Generate and Execute in DEV, Execute Preloaded in QA and PRD. With the DEV environment open for development, you design your DS jobs in DEV. DS Generates ABAP code according to the logic in the ABAP data flows. Once you're happy with the job results in DEV, you have the ABAP code transported (eg. using SAP Solution Manager) to QA and eventually to PRD. You normally won't get the authorization to generate ABAP code in QA and PRD environments anyway.

Former Member
0 Kudos

This is a good idea (and pretty obvious, in hindsight).

I think my problem was we currently have the same user permissions for our DS role on all systems, so I was assuming we would do this the same going forward.

Thanks so much!

Answers (0)