...
It is mandatory to develop ABAP Cloud Standard compliant code where ever possible the default ABAP language version assigned to the packages should be "ABAP Cloud". But due If the development is pure classic ABAP, i.e. exits or classic Badis then choose Standard ABAP for the dev id package, Due to a lack of compliant standard objects, if a development requires both types then the main dev id package should be ABAP Cloud and a child package needs to be created of type Standard ABAP with the same name root and "_CL" at the end. That allows us to follow ABAP Cloud standard as a mandatory guideline but legacy objects or classic ABAP as well.
Note the package prefix in bold illustrates the requirement for the child package to reflect the parent package name in its prefix.
...
Classic user exits are implemented in Z includes. The name is mandated by SAP. For these the package ZCUSTOM exists. The dev id package, to be created under it, naming stays as is except that /SYQ/ is being replaced with Z. Standard ABAP to be picked for the package.
Rule | The name of the package must follow the prescribed pattern. The package name will use a prefix which clearly identifies its parent. |
...
A namespace prefix that indicates the owner of the object. The SAP standards for this are:
Objects starting with a /SYQ/ are considered Customer Objects. Syensqo has its own custom namespace.
- Objects starting with ZZ1 /SYQ/ have been created with key user extensibility tools.
Objects starting with a Y are considered local Customer Objects only to be used for temporary POCs.
Objects starting with /…/ other than /SYQ/ have been created using a prefix namespace registered to another specific organization. This may be SAP or a SAP Partner.
All other objects belong to SAP
In specific circumstances the type of repository object is encoded in the prefix, for example CL for Class or T for Table. Most repository objects are only accessed from the Object Navigator or the Project Explorer where they are organized by object type making encoding redundant. Encoding becomes important if the repository object is referenced in the source code where it can’t be seen in the context of the repository.
A descriptive name for the object. This may contain encoded information about the functional area or business process that the object belongs to. The name needs to ensure that the functional alignment to the process reference model is clear.
...
Object Type | Pattern | Characters | Example | |
Adobe Form (with Fragments) | [NS][NAME] | 30 | /SYQ/MAIL_REDIRECTION_NOTICE | |
Adobe Form Interface | [NS][NAME] | 30 | /SYQ/PRODUCT_FACT_SHEET | |
Message Class | [NS][NAME] | 20 | /SYQ/FI_MASTER_DATA | |
ABAP Transformation | [NS][NAME] | 40 | /SYQ/COST_OBJECT_TO_JSON | |
Authorization Object | [NS][NAME] | 10 | /SYQ/COSTC | |
Shared Object Area Class | [NS][NAME] | 30 | /SYQ/PRODUCT_CACHE | |
Key User Extensibility Apps
Key user extensibility apps like the Custom Fields & Logic applications are used to create custom fields and Badi implementations in a clean core compliant way. The fields can be added/ published to CDS model, Service model, UI & Reports, Email & Form templates. Clean core compliant BAdIs are also being implemented using the apps.
...
Key User Extensibility Object Naming
...
Syntax
...
Convention
...
Example
...
Label / Description
...
<Meaningful Label or Description>
...
Order No.
...
Identifier
...
<SAP Prefix>_<Label>_<SAP Suffix>
...
ZZ1_OrderNo_BDC
...
Tooltip
...
<Meaningful Description>
...
Purchase Order Document Number
Release Contracts
In ABAP Cloud, the "Release Contract" is the formal mechanism that turns a custom object into a stable repository object and determines how it can be used or extended. Without this, the object remains "internal" and restricted.
Contract types are:
Contract C0: Extend: This contract ensures stability at dedicated extension points in APIs to allow extensibility.
Contract C1: Use System-Internally: This contract ensures a technically stable public interface for use in custom development objects created in the ABAP development tools for Eclipse, or using key user apps like Custom Business Objects or Custom CDS Views.
Contract C2: Use as Remote API: This contract ensures a technically stable public interface for use as remote API.
Contract C3: Manage Configuration Content: This contract ensures a stable persistence for own configuration content that can be exported, imported, displayed, and edited using dedicated APIs and editors.
Contract C4: Use in ABAP-Managed Database Procedures: This contract ensures a technically stable public interface for use in ABAP-Managed Database Procedures (AMDP).
Contract type C0 is not to be used.
Contract type C1 and C2 are the main contract types.
Contract type C3 is implicitly set by SAP for all configuration tables and does not need to be set.
Contract type C4 is only for AMDP and optional.
Rule | In ABAP Cloud developments assign release contract C1 for locally used CDS views and classes and C2 for APIs. |
Key User Extensibility Apps
Key user extensibility apps like the Custom Fields & Logic applications are used to create custom fields and Badi implementations in a clean core compliant way. The fields can be added/ published to CDS model, Service model, UI & Reports, Email & Form templates. Clean core compliant BAdIs are also being implemented using the apps.
Key User Extensibility Object Naming | ||
Syntax | Convention | Example |
Label / Description | <Meaningful Label or Description> | Order No. |
Identifier | /SYQ/<Label>_<SAP Suffix> | /SYQ/OrderNo_BDC |
Tooltip | <Meaningful Description> | Purchase Order Document Number |
The Custom Fields & Logic apps support different scope to be activated to use the new custom fields. Activation of all backend related field integrations for available oData, SOAP and BAPI to be done by default. UIs and Reports, Email and Form Templates, Business Scenarios based on specification requirement only. Other Extensibility apps to maintain forms templates, logos and more exist.
Rule | Use the Custom Fields & Logic app whenever possible to follow SAP's roadmap to Clean Core. |
Business Event Consumption
| Anchor |
|---|
The Custom Fields & Logic apps support different scope to be activated to use the new custom fields. Activation of all backend related field integrations for available oData, SOAP and BAPI to be done by default. UIs and Reports, Email and Form Templates, Business Scenarios based on specification requirement only. Other Extensibility apps to maintain forms templates, logos and more exist.
Since these custom objects are managed by SAP, we will not use the /SYQ/ namespace, except for the package having the /SYQ/ naming. By keeping the standard naming prefix of ZZ1_ the key user extensibility objects are easily identified.
...
Rule
...
Use the Custom Fields & Logic app whenever possible to follow SAP's roadmap to Clean Core.
Business Event Consumption
| Anchor | |||
|---|---|---|---|
|
...
Custom Workflows need to be built using the Classic Business Workflow or Flexible Workflow or BTP BPA. That complies with SAP’s clean core approach. The business objects and custom logic have to be done in ABAP OO and RAP.
Transaction code SWDD_SCENARIO instead of SWDD is used for Flexible Workflows. Using Flexible Workflows allows for flow configurations via the app “Manage Workflow”, but has many limitations. For the agent determination the new “Responsibility Management” app .If the agent determination has parallel branches with separate agent groups it may be needed to build the Workflow using BTP’s Build Process Automation. But that should be the exception and design should not have such complexity requiredis used.
Guide | S/4HANA Custom Workflows to be built as Flexible Workflows. |
Rule | Cross-system Custom Workflows to be built in BTP BPA. |
ABAP Authorization Group
Custom ABAP code and tables will have a custom authorization group assigned to them to provide the mechanism to restrict access to them by users.
For these custom developments the table below will be used depending on the relevant functional module. The object BRGRU has a maximum of four characters to create a unique authorization group with. The object(s) will be created using transaction SE54.
To have a consistent naming convention for custom authorization groups, use the entries in the table for tables and programs.
Classic Workflows where no standard flexible WF exists. | |||
Rule | Cross-system Custom Workflows to be built in BTP BPA. | ||
MODULE | CODE | ABAP | TABLE |
Financial Accounting | FI | ZFI | ZFIT |
Controlling | CO | ZCO | ZCOT |
Investment Management | IM | ZIM | ZIMT |
Treasury | TR | ZTR | ZTRT |
Enterprise Control | EC | ZEC | ZECT |
Material Management | MM | ZMM | ZMMT |
Sales & Distribution | SD | ZSD | ZSDT |
Production, Planning & Control | PP | ZPP | ZPPT |
Product Data Management | PDM | ZPDM | ZPXT |
Quality Management | QM | ZQM | ZQMT |
Plant Maintenance | PM | ZPM | ZPMT |
Service Management | SM | ZSM | ZSMT |
Project Systems | PS | ZPS | ZPST |
Personnel Development | PD | ZPD | ZPDT |
Payroll Accounting | PA | ZPA | ZPAT |
Organizational Management | OM | ZOM | ZOMT |
Time Management | TM | ZTM | ZTMT | Rule | SAP supplied authorization group &NC& will not be used at Syensqo
ABAP Authorization Check
Authorization checks are needed to limit access to data or to restrict who can create/update/delete data.
The ABAP keyword AUTHORITY-CHECK is deprecated in ABAP Cloud. Instead, the authorization checks need to be added to CDS view entities using DCLs (Data Control Language) to restrict access or inside the RAP Behavior handler class.
The authorization object tracker has to be updated to allow the security team to incorporate the objects in Syway roles.
...
Rule | Custom code must always be executed in the context of an authorized user, i.e. after an authorization check has been performed by the system. For code directly invoked by a user, an explicit authorization check must be performed before business or data access logic is executed. Relying purely on Start authorization is not enough to meet these criteria. Custom code executed within an already-authorized context (e.g. most BAdIs, user exits, enhancement spot implementations, etc), is exempt from this requirement because the check would have been performed by the standard SAP code. |
Custom Authorization Objects
Custom authorization objects will be created in SU21 or ADT with namespace /SYQ/ and assigned to authorization class /SYQ. ABAP language needs to be ABAP Cloud and the release contract C1 should be set to allow future proofing. At least the default authorization field ACTIVITY needs to be maintained.
Once created it needs to be used in the code or DCL or assigned to the object it controls via SU24.
SAP Screen Personas
SAP Screen Personas can be used to turn existing ERP Webgui screens into a simplified application for desktop and mobile. Native Ui5 apps are always preferred, but some transaction codes (T-codes) are still required to be used and can benefit from SAP Screen Personas especially to enable use on mobile devices.
...