Studio best practices
Use these best practices for Transaction and Query to streamline your script and query production processes and get solutions up and running more quickly.
- ALWAYS walk through the t-code in SAP before recording. This will ensure you know the process to be recorded and have data for the recording.
- Practice, record, and test your scripts and queries in a non-production SAP system to ensure that no erroneous data is added to a production system.
- Name files with the t-code, description, date created, and your initials for reference: VA01_NewSalesOrder_09302015_CRB.txr.
- Always add _GUI to the name a script that is recorded in GUI Scripting mode. Later, you will be able to identify those scripts quickly.
- For transactions with selectable views, always clear the default views by clicking the Deselect all button in the recording.
- Do not use a loop to update items. If one item update fails, the entire transaction fails.
- Do not use validation on an HR transaction because data is committed to the back end after each screen.
Exception: PA30 and PA40 are supported if Winshuttle Function Module v11.1 or later is installed.
- In ME21N, disable all BDC Cursor positions up to the point where the filter is selected. Otherwise, Transaction will have trouble locating these when navigating the second time around.
- Check that Save (OK code) is sitting within its own screen at the very end of the script, after any mapped fields. This will make validation work.
- Before you create a query by recording a transaction code, go to the Admin Defaults tab in the Options box and increase the maximum number of tables that you can use (Query 10.x only).
- Run multiple-table Query scripts as an SAP background process to avoid affecting the SAP server performance.
- Always use Selection criteria in a query so that you extract just what you need.
- Joins between Primary Key fields always have the best performance. Joins between Index fields have the next-best performance.
- Creating a join between non-indexed fields will degrade the performance of data extraction.
- Inner join queries are always recommended, because a left outer join will degrade the performance of data extraction.
- It is always better to do a preview run before you publish a query to be run in the production environment. The preview run will confirm that the required data exists and that the query is correctly formed.
- Use Adaptive Query Throttling (AQT) mode for execution, so that the Query run will not affect the SAP server performance.
- Use Direct Execution mode (non-AQT) to run queries that will extract fewer than a thousand items.
- Applying criteria on non-Indexed fields will degrade the performance of data extraction.
- Use Data Chunking in Query when running large data downloads to avoid network bottlenecks.
- Creating Queries using View and Transparent tables gives better performance than Cluster and Pool tables, which are normally heavier in size.
- Remove any unnecessary tables, fields, and joins in a Query script to get better performance in production.
- Use the Text result destination, or data type, to write data in faster than the Excel, Access, XML, SQL Server, and SharePoint data types.
Note: The account that you use to write to SQL Server must have db_owner or db_ddladmin membership on the database that contains the target table.
- Always check the Number of Entries on the Workspace tab to validate number of records that will be extracted with Query.
- Use selection criteria on the join fields when you have very large queries. The join fields are usually the Primary key fields.