Authorisation (General)

Background

Promenta solutions run within SAP and so where possible SAP standard authorisations are used. This document describes some exceptions where additional SAP authorisations are required and also any specific Promenta authorisations.

It should be noted that end-users access the main functionality via the web-based interface. As such most end-users will not be accessing using transaction codes from SAPGui. Administrators do run reports and tools in SAPGui and so will need access to transaction codes.

Important Note
Where SAP standard authorisation objects are mentioned it is the responsibility of the customer to ensure that they are used correctly in conjunction with any authorisations a user may have and as detailed in SAPs documentation. The information about standard SAP authorisation objects is provided as a guide only – check SAP documentation for definitive information.

See here for specific information on SAP authorisations

Administration (Promenta authorisation)
Various reports check the authorisation object YZYBULCONS to control access. This object is shown in the YZY_MYCOMMSCENTRE_ADMIN role

Analyser (Promenta authorisation)

This access is required to view request status
Auth object : YZYBULCONS
ACTVT [activity]  = 03 (display)

This access is required to gain full access
Auth object : YZYBULCONS
ACTVT [activity]  = 70 (Administer)

This access is required to open requests in a browser (read-only) when using the read-only analyser transaction /PROMENTA/WFRM_ASR_D. However if the user has access ACTVT=70 (Administer) is assigned then this is not required.
Auth object : YZYBULCONS
ACTVT [activity]  = A5 (display records)

Restrict Webflow access (Promenta authorisation)

It is possible to restrict which webflows can be executed using the object below. If a user without authorisation to open a specific webflow somehow gets the URL to start one they will get an error message.

Note : By default the model roles grant access to all webflows.

Auth object : YZYMCCFORM
YZYMFORMID [webflow id]  = the Id of the allowed webflow.
ACTVT [activity]  = 03 (display)

Since SP23 : Some solutions may also check for 01 (create) or 02 (change) in addition to the 03 (display) authorisation.

Restrict DataFlow access (Promenta authorisation)

All Dataflow applications use the same value for FORMID (/PROMENTA/DATAFLOW) so provide restriction for dataflow process codes an additional check is provided. Not that access to the DataFlow form id is also required (see above).

Auth object  :YZYWS00001
YZYMFORMID [webflow id]  = /PROMENTA/DATAFLOW
YZYWSKEY1   [Key 1] = XKEY
YZYWSKEY2  [Key 2] = <the process ID>
ACTVT [activity]  =  03 (display)

Generic Application Authorisation – Organisation level (Promenta authorisation)

Object YZYWS00002 performs the same task as object YZYWS00001 but includes a specific field for Company Code OrgLevel control. This is normally used in derived roles.

Auth object  :YZYWS00002
YZYMFORMID [webflow id]  = the Id of the allowed webflow.
YZYWSKEY1   [Key 1] = the first level of restriction
YZYWSKEY2  [Key 2] = the second level of restriction

BUKRS =Company code at Org Level
ACTVT [activity]  = example values are 01(create), 02(change), 03 (display) but more are possible

Launchpad Authorisations

Users must have the correct authorizations to enable specific Launchpad menu options. The authorisation object is YZYLNCH001

Auth object : YZYLNCH001

YZYLNCH001  [Menu option] = the menu option code
ACTVT [Activity]   = 03 (Display)

Document Template Manager
Administration users must have the following authorisations:

Auth object YZYWS00001
– YZYMFORMID  = /PROMENTA/WSFI_DOCS
– YZYWSKEY1  = ADMIN
– YZYWSKEY2 = *  (all)
ACTVT [activity]  =01

Journals 
Journal process codes can be restricted – with object  YZYWSFI001.

Superuser Mode (Dataflow)

Dataflow has a superuser mode (see here for description and additional settings needed). This section describes the authorisations needed

This authorisation relates only to dataflow and uses the same process ID as the dataflow restriction check above

Check 1 : Check if user can use the superuser mode

Auth object YZYWS00001
– YZYMFORMID  = /PROMENTA/DATAFLOW
– YZYWSKEY1  = SUPERUSER
– YZYWSKEY2 = <the process ID>
ACTVT [activity]  =16

Check 2 : check if user can use the RFC destination (if not then the users own ID is used for read and update tasks). If this is activated all updates will occur without workflow approval AND using the update user. This should be used with caution.

Auth object YZYWS00001
– YZYMFORMID  = /PROMENTA/DATAFLOW
– YZYWSKEY1  = SUPERUSER_RFCOK
– YZYWSKEY2 = <the process ID>
ACTVT [activity]  =16

Promenta tech note : implemented in /PROMENTA/TMPL_DF_BASE->DF_SET_SUPERUSER

 

Generic authorisations for custom checks

Generic Application Authorisation (Promenta authorisation)

Note : Promenta reserves the right to use this object for our own purpses along side custom usage.

It is often the case that a customer requires a specific custom authorisation check in a process that is not covered by an SAP authorisation. Rather than create separate objects for each requirement Promenta will use it’s Generic Application Authorisation object which enables up to two levels of control and can be restricted to a specific webflow formid.

The use of the object for a particular process will be communicated directly but the generic information is below.

Auth object  :YZYWS00001
YZYMFORMID [webflow id]  = the Id of the allowed webflow.
YZYWSKEY1   [Key 1] = the first level of restriction
YZYWSKEY2  [Key 2] = the second level of restriction
ACTVT [activity]  = example values are 01(create), 02(change), 03 (display) but more are possible

Example
If a a customer required a specific check of Company code GB01 and purchase organisation  0001  in a webflow ZZAUTHDEMO the object would be :

YZYWS00001
– YZYMFORMID  = ZZAUTHDEMO
– YZYWSKEY1  = GB01 (the company code)
– YZYWSKEY2 = 0001 (the purchase org)

Scroll to Top