WFM Installation - 20.1 and earlier versions

Customers who cannot record or run Non-Batch Transaction scripts on a given SAP system will not be able to call SAP transactions over RFC unless they either:

1. Install the WFM (recommended), or

2. If the WFM is not available, take one of these three steps (listed in order of preference):

  • Elevated SAP Access: Auth object S_DEVELOP, activity 16, object name*, and object type SCAT
  • ECATT/CATT enabled on specific SAP server
  • Removal of the authorization check that was inserted by SAP

The WFM is required in any of the following situations:

  1. The SAP ECC 6 Enhancement Pack 4 and above (SAP BASIS 700 Support Package 24 and above) has been installed on the client environment.
    The patch levels affected are provided here: SAP BASIS 7.00 Support Package 24 (Non-batch-input scripts stopped working - no messages returned from SAP.)
  2. The WFM is installed on the SAP Server, and normally the Basis team moves the WFM to the SAP server via SAINT. Complete instructions are included in the WFM installation files.
  3. Transport releases for 7.00, 7.0x, 7.31, 7.40 and 7.50. (This applies to transport releases 7.00, 7.0x, 7.31, 7.40 and 7.50 that are same as of 7.00.)
    Please refer to the following information regarding Importing Query or Transaction Function Module transport errors

While applying any Winshuttle transport to your system, you may receive the following error:
"X of X requests do not match the component version of the target system" (see screenshot below).

To address this, re-run the import with one or more of the following options selected:

  • Leave Transport Request in Queue
  • Import Transport Request Again
  • Ignore Invalid Component Version (Assuming that the versions of the components are newer on the customer system, select this final option to override SAP and complete the import.)

WFM Installation Support Articles

Finding the Winshuttle Function Module version

How to check the Winshuttle Function Module Installation

WFM Authorizations

Authorization checks on the calls to self Remote Function Module (RFM) and standard RFMs under Virtual Forge profiler changes, as noted here:

  • WFM RFMs self check : /WINSHTLQ/*
  • LDB process via WFM : SDIFRUNTIME
  • Orphaned Chunk clearing in WFM : SG
  • Infoset SQ02, Queries SQ01 in WFM : AQCF
  • Record in WFM : SBDR, SCP2
  • Record ,User Format in WFM : RFC1, SU_USER
  • Background Query run in WFM : BDL3, THFB
  • Calculate prices BAPI call in WFM: WVK8
  • Value help WFM (F4)

Vendor/Customer master functionality call via Direct in the WFM.

Authorizations for use if the WFM is not used: 

  • RFC access is still required
  • TCode access is still required
  • Scripts need to be Batch or GUI Scripting*
  • Non-Batch scripts can only be created or used if developer authorizations are granted
  • Authorizations list: 
    • OBJNAME: ‘*’
    • ACTVT: ‘16’ (=execute)

Authorizations as per Studio 11 pre-ship 3 WFM roles. These roles are also relevant for the non-WFM mode.

  • /WINSHTLQ/CMN_ADMIN_ROLE (Winshuttle role for ADMIN)
  • /WINSHTLQ/CMN_AUTHOR_ROLE (Winshuttle role for AUTHOR)
  • /WINSHTLQ/CMN_RUNNER_ROLE (Winshuttle role for RUNNER)