Help Center>Studio v11 (Foundation)

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.

Transaction

  • 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.

Query

  • 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.