Hierarchy
GRCFND_A (Software Component) GRC Foundation ABAP⤷
GRC-SPC (Application Component) Process Controls⤷
GRPC_CUSTOMIZING (Package) Customizing
IMG Activity
| ID | GRPC_SHAREDOBJECT | Activate Shared Objects Memory |
| Transaction Code | S_GR1_31000097 | (empty) |
| Created on | 20071106 | |
| Customizing Attributes | GRPC_SHAREDOBJECT | Activate Shared Object Memory |
| Customizing Activity | GRPC_SHAREDOBJECT | Activate Shared Objects Memory |
Document
| Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
| Document Name | GRPC_SHAREDOBJECTMEMORY |
Use
In this Customizing activity, you can activate the use of the Shared Objects Memory in GRC for the following data:
- Organizational Hierarchy
- Account Group Hierarchy
- Indirect Entity-Level Controls Catalog
- Central Process Catalog
- Processes of the Organization
Activate Shared Objects Memory if you are having performance issues.
It is not possible to use the Shared Objects Memory for all other objects transferred from organizations (such as entity-level controls).
Using the Shared Objects Memory improves system performance when calling up data in the corresponding Web applications (such as the Portal). When the Shared Objects Memory is activated for the organizational hierarchy, for example, and a user calls up the organizational hierarchy, the system creates a buffer for the organizational hierarchy in the relevant timeframe and loads the data into the buffer. When another user then calls up the organizational hierarchy in the same timeframe, the data is loaded from the buffer, not from the database. However, if the personalized timeframe of the user does not agree exactly with the timeframe of the buffer, then, instead of accessing the buffer, the user accesses the database directly.
When the Shared Objects Memory is activated for the central structures and catalogs, the system creates a separate area instance for each timeframe. When the Shared Objects Memory is activated for the processes transferred from an organization, the system creates a separate area instance for each organization and timeframe.
To ensure that performance is improved, only activate the Shared Objects Memory if users generally call up the data with read-only access.
Requirements
Standard settings
Activities
- Activate the Shared Objects Memory (if needed) by entering each object type and timeframe for which you want to use the shared memory.
- Deactivate the Shared Objects Memory by deleting the given entry for the object type and timeframe. Doing so removes all existing area instance versions.
- In the IMG activity Monitor Active Areas (transaction SHMM), you can monitor which area instances exist in the system.
Example
Memory is only accessed exactly as it is entered. In other words, if the Timeframe Selected differs from what is entered, users revert to accessing the database. For example, if you activate the Shared Objects Memory and specify the timeframe Year 200X, users only access the Shared Objects Memory for Year 200X (not if they enter 2nd Quarter 200X).
- Year 200X -> Shared Objects Memory
- 2nd Quarter 200X -> Database
Business Attributes
| ASAP Roadmap ID | 201 | Make global settings |
| Mandatory / Optional | 1 | Mandatory activity |
| Critical / Non-Critical | 2 | Non-critical |
| Country-Dependency | A | Valid for all countries |
Maintenance Objects
| Maintenance object type | C | Customizing Object |
| Assigned objects | ||||||
|---|---|---|---|---|---|---|
| Customizing Object | Object Type | Transaction Code | Sub-object | Do not Summarize | Skip Subset Dialog Box | Description for multiple selections |
| GRPCSHM2 | S - Table (with text table) | SM30 |
History
| Last changed by/on | SAP | 20111118 |
| SAP Release Created in | 250 |
