Help Center>Studio (Connect)

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.