| Oracle® Retail Allocation Operations Guide Release 14.1 E57847-01 |
|
 Previous |
 Next |
This chapter is intended for administrators who support and monitor the running system.
The content in this chapter is not procedural, but is meant to provide descriptive overviews of the key system parameters.
This section covers the following topics:
Applications may need to execute operations that can take significant time to complete.
Executing these operations in the application's own thread cause the application to block other operations until those long-running operations complete.
In contrast, being able to assign the long-running operations to background threads allows the foreground thread to remain active and service further user requests. This is also described as launching those operations asynchronously.
For example, in the Allocation application, when an allocation request is submitted for approval, the system needs to perform a comprehensive validation to ensure that the allocation is valid. The validation should be performed asynchronously. You can proceed with performing other operations within the system. Once the background validation is complete, you are notified.
Retail applications achieve asynchronous processing through the use of Java Messaging Service (JMS). When you, for instance, through the application UI screen, submit a business entity for processing asynchronously, the application goes through a process depicted in the diagram below:
The Retail application's producer process executes to collect the user request for asynchronous processing and stores that information into a database table called RAF_ASYNC_TASK. This table serves as a log of asynchronous processing requests as well as storage for any kind of context information in order to complete the processing. For example, the unique identifier of the business object such as an allocation being submitted for asynchronous calculation.
The producer method creates a queue message and sends it to a JMS Queue.
One or more instances of Message Driven Beans (MDB) are configured to listen to the JMS Queue.
When messages are detected on the queue, the MDBs are dispatched to execute a task asynchronously. The MDB reads the context information about the task from the TASK table.
The MDB executes the required processing for the task.
The following resources in the WebLogic Administrator Console application should be configured in order to allow asynchronous processing to function in a Retail application:
Table 4-1 WebLogic Administrator Console Resources
| WebLogic Server Resource | Required Names/References | Configuration Notes |
|---|---|---|
|
JMS Server |
Any name can be used. |
None. Defaults provided by WebLogic acceptable. |
|
JMS Module |
Any name can be used. |
None. Defaults provided by WebLogic acceptable. |
|
JMS Queue |
Name: calcQueue JNDI: oracle.retail.apps.alc.async.AllocCalcQueue |
|
|
JMS Queue Connection Factory |
Name: allocCalcQueueCF JNDI: oracle.retail.apps.alc.async.AllocCalcQueueCF |
|
|
Work Manager |
Name: AllocWorkManager |
|
For detailed information on configuring the above resources, see the WebLogic documentation at http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html.
The RAF_ASYNC_TASK table can be used to view error codes for failures, and to monitor for any failures requiring triage from production support team. As described in the section, Overview of Asynchronous Processes in Retail Applications, each asynchronous processing request is logged as a row in the RAF_ASYNC_TASKS table. As the task is sent to the queue, picked up and completed by the consuming message driven bean, the rows in this table are updated with status information.
Table 4-2 RAF_ASYNC_TASK Table Details
| RAF_ASYNC_TASK Column | Description |
|---|---|
|
ASYNC_TASK_ID |
A unique identifier for each row in this table. Each asynchronous task is given a unique ASYNC_TASK_ID. |
|
APPLICATION_CODE |
A code representing the Retail Application that generated the asynchronous task. |
|
TASK_DESC |
A short description of the asynchronous task. |
|
TASK_CONTEXT |
A string containing information needed to process the asynchronous task. Usually indicates the ID of the business entity to be processed (example: the ID of the allocation request to be approved) |
|
STATUS |
The status of the asynchronous task.
|
|
TASK_COMMAND_CLASS_NAME |
A fully-qualified Java class name that contains the business logic for completing the task. |
|
PUBLISH_TIMESTAMP |
The time and date when the asynchronous task was published. That is, when the status was changed to NEW. |
|
PROCESS_START_TIMESTAMP |
The time and date when processing of the asynchronous task started. That is, when the status was changed to IN-PROGRESS. |
|
PROCESS_END_TIMESTAMP |
The time and date when the processing of the asynchronous task ended with either a SUCCESS or FAILED status. |
|
PROCESS_ERROR_TXT |
When the status is FAILED, this column would contain information about the failure. The server logs may need to be inspected for more detailed information about the cause of the processing failure.
|
|
CREATED_BY |
Audit field pertaining to the logged in application user that requested the task. |
|
CREATE_DATE |
Audit field pertaining to when the row was created. |
|
LAST_UPDATED_BY |
Audit field pertaining to the user that last updated the row. |
|
LAST_UPDATE_DATE |
Audit field pertaining to the last date/time when the row was updated. |
As previously mentioned, each asynchronous task is logged as a row in the RAF_ASYNC_TASK table. Over time, this table can grow significantly which can degrade performance of the asynchronous task mechanism.
It is recommended that you periodically purge this table.
Retail applications provide a simple PL/SQL function to purge contents of the RAF_ASYNC_TASK table based on retention time period (in days).
create or replace
PACKAGE BODY RAF_ASYNC_TASK_PKG AS
FUNCTION UPDATE_ASYNC_TASK_AUTOTRAN(
IN_ASYNC_TASK_ID IN NUMBER,
IN_STATUS IN VARCHAR2,
IN_PROCESS_START_TIMESTAMP IN TIMESTAMP,
IN_PROCESS_END_TIMESTAMP IN TIMESTAMP,
IN_ERROR_TEXT IN VARCHAR2,
IN_LAST_UPDATE_DATE IN TIMESTAMP,
IN_USER_ID IN VARCHAR2,
IN_OBJ_VER_NUM IN NUMBER
) RETURN NUMBER AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
UPDATE RAF_ASYNC_TASK
SET STATUS = IN_STATUS,
PROCESS_START_TIMESTAMP = IN_PROCESS_START_TIMESTAMP,
PROCESS_END_TIMESTAMP = IN_PROCESS_END_TIMESTAMP,
PROCESS_ERROR_TXT = IN_ERROR_TEXT,
LAST_UPDATE_DATE = IN_LAST_UPDATE_DATE,
LAST_UPDATED_BY = IN_USER_ID,
OBJECT_VERSION_NUMBER = IN_OBJ_VER_NUM
WHERE ASYNC_TASK_ID = IN_ASYNC_TASK_ID;
COMMIT;
RETURN 0;
END;
FUNCTION DELETE_ASYNC_TASK(
IN_NUMBER_OF_DAYS IN NUMBER
) RETURN NUMBER IS
BEGIN
DELETE from RAF_ASYNC_TASK where last_update_date < sysdate-IN_NUMBER_OF_DAYS;
RETURN 0;
END;
END RAF_ASYNC_TASK_PKG;
This section covers the following topics:
Retail applications provide the ability to notify authenticated users in the application when business events occur. An example of a business event is when a background asynchronous task such as an approval of an allocation or a validation of a price change has completed. Typically, you are expected to take action on these notifications.
When a notification is generated for you, the notification icon on the Retail application's global area appears along with a count of the number of pending notifications for the user.
A popup is presented to you when he/she clicks on the notification icon. The popup shows all the notifications that are pending user action. Clicking on the link for each notification opens the specific UI flow that allows you to address any pending action for the notification.
Notifications are represented as rows in the RAF_NOTIFICATION table. Over time, depending on how notifications are being generated by the application, the rows in this table can grow potentially degrading performance of the notifications feature.
The notifications table will be completely purged nightly when running Allocation daily clean up batch process.
This section discusses the functional security for Retail applications and the components used to implement it. Functional security is based on OPSS. For more information on OPSS, see the Oracle Fusion Middleware Application Security Guide.
This section covers the following topics:
Users are not assigned to permissions directly; rather access is assigned to roles. Roles group particular permissions required to accomplish a task; instead of assigning individual permissions, roles match users with the permissions required to complete their particular task.
There are two main types of roles, enterprise and application.
The Identity Store contains enterprise roles that are available across applications. These are created as groups in LDAP, making them available across applications.
Applicable Retail applications security provides four types of roles: abstract, job, duty, and privilege.
Applicable Retail applications record job, abstract roles as enterprise roles and duty, privilege roles as application roles.
Application roles are stored in the application-specific policy store. These roles and role mappings are described in the jazn-data.xml file under the policy stripe 'ALC_CORE'.
Abstract roles are associated with a user, irrespective of their job or job function. These are also roles that are not associated with a job or duty. These roles are normally assigned by the system (based on user attributes), but can be provisioned to a user on request.
Naming Convention: All the Retail Abstract role names end with' _ABSTRACT'
Example: APPLICATION_ADMIN_ABSTRACT
Job roles are associated with the job of an employee. An employee with this job can have many job functions or job duties.
|
Note: These roles are called Job roles as the role names closely map to the jobs commonly found in most organizations. |
Naming Convention: All the Retail Job role names end with' _JOB'
Example: ALLOCATOR_JOB.
Job duties are tasks one must do on a job. A person is hired into a job role. These are the responsibilities one has for a job.
Duty roles are roles that are associated with a specific duty or a logical grouping of tasks. Generally, the list of duties for a job is a good indicator of what duty roles should be defined.
Duty roles should:
Read as a job description at a job posting site.
Duties that we create should be self-contained and pluggable into any existing or new job or abstract role.
Naming Convention: All the Retail duty role names end with' _DUTY'
Example: ALC_ALLOC_POLICY_MAINTENANCE_MANAGEMENT_DUTY
Privilege is the logical collection of permissions. A privilege can be associated with any number of User Interface components. Privileges are expressed as application roles.
Naming Convention: All the Retail Privilege role names end with' _PRIV'
Example: ALC_ALLOC_SEARCH_PRIV
Privilege roles carry security grants.
Example:
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.
ApplicationRole</class>
<name>ALC_ALLOC_SEARCH_PRIV</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.adf.controller.security.TaskFlowPermission</class>
<name>/oracle/retail/apps/alc/allocsummary/publicUi
/flow/AllocationSummaryFlow.xml#AllocationSummaryFlow</name>
<actions>view</actions>
</permission>
</permissions>
</grant>
Retail role hierarchies are structured to reflect the Retail business process model.
Job roles inherit duty roles. For example, the Allocator Job role inherits the ALC_ALLOC_SYSTEM_OPTIONS_INQUIRY_DUTY roles.
<app-role>
<name>ALC_ALLOC_SYSTEM_OPTIONS_INQUIRY_DUTY</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.internal.core.principals.
JpsXmlEnterpriseRoleImpl</class>
<name>ALLOCATOR_JOB</name>
</member>
</members>
</app-role>
Duty roles inherit Privilege roles. Duty roles can inherit one or more other Duty roles.
Example: ALC_ALLOC_SIZE_PROFILE_MANAGEMENT_DUTY inherits ALC_ALLOC_SIZE_PROFILE_INQUIRY_DUTY role.
<app-role>
<name>ALC_ALLOC_SIZE_PROFILE_INQUIRY_DUTY</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.internal.core.principals.
JpsXmlEnterpriseRoleImpl</class>
<name>BUYER_JOB</name>
</member>
<member>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>ALC_ALLOC_SIZE_PROFILE_MANAGEMENT_DUTY</name>
</member>
</members>
</app-role>
Example: ALC_ALLOC_SIZE_PROFILE_INQUIRY_DUTY role inherits the ALC_ALLOC_SIZE_PROFILE_VIEW_PRIV role
<app-role> <name>ALC_ALLOC_SIZE_PROFILE_VIEW_PRIV</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <name>ALC_ALLOC_SIZE_PROFILE_INQUIRY_DUTY</name> </member> </members> </app-role>
Retail applications ship with default security reference implementations. The source of truth for default reference implementation is the jazn-data.xml file.
|
Note: Make sure that the policy store is loaded with the default security configuration. For more information, see the Post Installation steps in the Oracle Retail Allocation Installation Guide. |
The common decisions made to match your enterprise to the default security reference implementation include the following:
Do the default job roles match the equivalent job roles in your enterprise?
Do the jobs in your enterprise exist in the security reference implementation?
Do the duties performed by the jobs in your enterprise match the duties in the security reference implementation?
|
Important: It is important when constructing a role hierarchy that circular dependencies are not introduced. The best practice is to leave the default security configuration in place and first incorporate your customized application roles in a test environment. |
Retail applications provide a way in which retailers can modify the default roles to map to their security groups through the Retail Application Security Role Manager (RASRM).
RASRM is installed along with the Retail application. Users with proper security privileges to access RASRM can launch RASRM by clicking on a link from the Retail Application's global menu.
For more information about using RASRM, see the Oracle Retail Merchandising Security Guide.
