Alloc 160 Og

Oracle®
[1] Retail Allocation

Operations Guide
Release 16.0
E81309-01
December 2016
Oracle® Retail Allocation Operations Guide, Release 16.0
E81309-01
Copyright © 2016, Oracle and/or its affiliates. All rights reserved.
Primary Author: Nathan Young

This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it
on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users
are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and
agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and
adaptation of the programs, including any operating system, integrated software, any programs installed on
the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to
the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management
applications. It is not developed or intended for use in any inherently dangerous applications, including
applications that may create a risk of personal injury. If you use this software or hardware in dangerous
applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other
measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages
caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks
are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD,
Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced
Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content,
products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and
expressly disclaim all warranties of any kind with respect to third-party content, products, and services
unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its
affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of
third-party content, products, or services, except as set forth in an applicable agreement between you and
Oracle.
Value-Added Reseller (VAR) Language
Oracle Retail VAR Applications
The following restrictions and provisions only apply to the programs referred to in this section and licensed
to you. You acknowledge that the programs may contain third party software (VAR applications) licensed to
Oracle. Depending upon your product and its version number, the VAR applications may include:
(i) the MicroStrategy Components developed and licensed by MicroStrategy Services Corporation
(MicroStrategy) of McLean, Virginia to Oracle and imbedded in the MicroStrategy for Oracle Retail Data
Warehouse and MicroStrategy for Oracle Retail Planning & Optimization applications.
(ii) the Wavelink component developed and licensed by Wavelink Corporation (Wavelink) of Kirkland,
Washington, to Oracle and imbedded in Oracle Retail Mobile Store Inventory Management.
(iii) the software component known as Access Via™ licensed by Access Via of Seattle, Washington, and
imbedded in Oracle Retail Signs and Oracle Retail Labels and Tags.
(iv) the software component known as Adobe Flex™ licensed by Adobe Systems Incorporated of San Jose,
California, and imbedded in Oracle Retail Promotion Planning & Optimization application.
You acknowledge and confirm that Oracle grants you use of only the object code of the VAR Applications.
Oracle will not deliver source code to the VAR Applications to you. Notwithstanding any other term or
condition of the agreement and this ordering document, you shall not cause or permit alteration of any VAR
Applications. For purposes of this section, "alteration" refers to all alterations, translations, upgrades,
enhancements, customizations or modifications of all or any portion of the VAR Applications including all
reconfigurations, reassembly or reverse assembly, re-engineering or reverse engineering and recompilations
or reverse compilations of the VAR Applications or any derivatives of the VAR Applications. You
acknowledge that it shall be a breach of the agreement to utilize the relationship, and/or confidential
information of the VAR Applications for purposes of competitive discovery.
The VAR Applications contain trade secrets of Oracle and Oracle's licensors and Customer shall not attempt,
cause, or permit the alteration, decompilation, reverse engineering, disassembly or other reduction of the
VAR Applications to a human perceivable form. Oracle reserves the right to replace, with functional
equivalent software, any of the VAR Applications in future releases of the applicable program.
Contents
Send Us Your Comments ....................................................................................................................... xiii
Preface ............................................................................................................................................................... xv
Audience..................................................................................................................................................... xv
Documentation Accessibility ................................................................................................................... xv
Related Documents ................................................................................................................................... xv
Customer Support ..................................................................................................................................... xvi
Review Patch Documentation ................................................................................................................. xvi
Improved Process for Oracle Retail Documentation Corrections ...................................................... xvi
Oracle Retail Documentation on the Oracle Technology Network .................................................. xvii
Conventions .............................................................................................................................................. xvii
1 Introduction
Allocation Overview................................................................................................................................ 1-1
2 Technical Architecture
Overview.................................................................................................................................................... 2-1
Oracle Application Development Framework (ADF) .................................................................. 2-1
Retail Fusion Platform ....................................................................................................................... 2-4
Allocation Backend Service .............................................................................................................. 2-4
Data Access Patterns.......................................................................................................................... 2-4
Data Storage ........................................................................................................................................ 2-4
3 Back-end System Administration and Configuration

Managing Asynchronous Processes ..................................................................................................... 3-1
Overview of Asynchronous Processes in Retail Applications .................................................... 3-1
Configuring JMS Resources for Asynchronous Processing ......................................................... 3-2
Monitoring Asynchronous Tasks Via the RAF_ASYNC_TASK Table....................................... 3-3
Purging the Asynchronous Tasks Table ......................................................................................... 3-4
Managing the Notifications Feature..................................................................................................... 3-5
Overview of Notifications in Retail Applications ......................................................................... 3-5
Purging the Notifications Table ....................................................................................................... 3-6
Notification ReST Services ................................................................................................................ 3-7
Enabling Mobile Push Notifications................................................................................................ 3-7
v
Prerequisite: Apple Certificate and Provisioning Profile...................................................... 3-7
Prerequisite: Android Google Cloud Messaging Registration............................................. 3-7
Server Configuration .................................................................................................................. 3-7
Managing Application Navigator ......................................................................................................... 3-8
Managing Functional Security............................................................................................................... 3-8
Introduction to Retail Roles .............................................................................................................. 3-8
Security Policy Stripe.................................................................................................................. 3-8
Abstract Roles.............................................................................................................................. 3-9
Job Roles ....................................................................................................................................... 3-9
Duty Roles.................................................................................................................................... 3-9
Privilege Roles ............................................................................................................................. 3-9
Retail Role Hierarchy...................................................................................................................... 3-10
Default Security Reference Implementation ............................................................................... 3-11
Privileges .................................................................................................................................. 3-11
Duties ........................................................................................................................................ 3-12
Role Mapping ........................................................................................................................... 3-13
Extending the Default Security Reference Implementation ..................................................... 3-14
Managing Roles in Retail Application Administration Console ...................................... 3-15
Disabling Content ........................................................................................................................... 3-16
Safe Mode.................................................................................................................................. 3-16
Disabling Links in the Sidebar ............................................................................................... 3-16
Managing Oracle Metadata Services (MDS) ............................................................................... 3-16
Overview of Oracle Metadata Services ................................................................................ 3-16
Using the System MBean Browser and the MDSAppRuntime MBean ........................... 3-17
Exporting All Metadata Services Customizations .............................................................. 3-20
Exporting Metadata Services Customization for a Specific User ..................................... 3-21
Deleting All Metadata Services Customizations for a User............................................... 3-22
Deleting a Customization for a Specific Page for All the Users ........................................ 3-22
Deleting a Customization for a Specific Page for a Particular User ................................. 3-23
Importing All Metadata Services Customizations .............................................................. 3-24
Importing a Specific Page Customization for a User.......................................................... 3-24
Creating Metadata Labels ....................................................................................................... 3-25
Promoting Metadata Labels ................................................................................................... 3-26
Listing Metadata Labels .......................................................................................................... 3-26
Deleting Metadata Labels ....................................................................................................... 3-26
4 Security in Retail Applications

Single Sign-on Setup for RAF Applications....................................................................................... 4-1
Displaying External Application Contents in Non-SSO Environments ....................................... 4-1
5 Web Services in Retail Applications

Common Characteristics of Retail Application ReSTful Web Services........................................ 5-1
Deployment......................................................................................................................................... 5-1
Security ................................................................................................................................................ 5-1
Standard Request and Response Headers...................................................................................... 5-1
Standard Error Response .................................................................................................................. 5-2
List of ReSTful Web Services ................................................................................................................ 5-2
vi
Platform ReSTful Web Services........................................................................................................ 5-2
Notification ReST Services......................................................................................................... 5-2
Access Control ReST Service ..................................................................................................... 5-3
Favorites ReST Services.............................................................................................................. 5-4
Allocations........................................................................................................................................... 5-4
Approve........................................................................................................................................ 5-4
Load Recent Allocations by User.............................................................................................. 5-5
Load by Query............................................................................................................................. 5-5
Load by Allocation ID ................................................................................................................ 5-6
Load Item Location Information............................................................................................... 5-6
Lookup Allocation Status .......................................................................................................... 5-7
Lookup Process Status................................................................................................................ 5-7
Reserve.......................................................................................................................................... 5-8
Submit........................................................................................................................................... 5-8
Withdraw ..................................................................................................................................... 5-8
6 In-Context Launching Task Flows in Retail Applications

Limitations of In-Context Launch via URLs ....................................................................................... 6-1
List of In-Context Launch Task Flows ................................................................................................. 6-1
Quick Create Allocation by Passing Source or Item IDs .............................................................. 6-1
Load Allocation .................................................................................................................................. 6-2
Quick Create Allocation by Passing Item Id and WH IDs ........................................................... 6-2
7 Customizing Retail Applications

Prerequisite Concepts.............................................................................................................................. 7-1
Understanding the Deployment of Retail Applications............................................................... 7-1
Understanding the Retail Application User Interface .................................................................. 7-2
Supported Customization Scenarios .................................................................................................... 7-4
Adding a Custom Shared Library ................................................................................................... 7-4
Downloading JDeveloper .......................................................................................................... 7-4
Creating the Custom Shared Library Workspace through JDeveloper .............................. 7-4
Generating and Deploying the Custom Shared Library WAR ......................................... 7-11
Referencing the Custom Shared Library from the Retail Application............................. 7-12
Creating New ADF Contents ........................................................................................................ 7-14
Custom Shared Library Must Be Regenerated .................................................................... 7-15
New Components Should Have Security Grants................................................................ 7-15
Applying ADF Best Practices ................................................................................................. 7-15
Task Flow and Page Configuration Must Be Supported.................................................... 7-15
The Same Data Source Must Be Used ................................................................................... 7-15
Adding or Modifying an Item in the Reports Menu.................................................................. 7-16
Reports Menu Model XML Items .......................................................................................... 7-17
Adding or Modifying an Item in the Tasks Menu ..................................................................... 7-20
Dashboard Customization Scenarios .......................................................................................... 7-21
Understanding Dashboards in Retail Applications ............................................................ 7-21
Adding a New ADF-based Dashboard in the Reports Menu ........................................... 7-23
Adding a New External Dashboard into the Reports Menu ............................................. 7-24
vii
Retail Application Included Dashboard Customization Scenarios .................................. 7-24
Adding Contextual Reports........................................................................................................... 7-35
List of Contextual Business Events and Payloads............................................................... 7-36
Preparing the Custom Shared Library for Adding Contextual Reports.......................... 7-37
Adding a URL based Contextual Report ............................................................................. 7-38
Adding a DVT Taskflow based Contextual Report ............................................................ 7-41
Enabling Dynamic Task Items in the Retail Application .......................................................... 7-43
The DynamicContentHandler Interface ............................................................................... 7-45
DynamicContent Type ............................................................................................................ 7-45
Example Implementation of the DynamicContentHandler Interface.............................. 7-46
TaskMenuItem class ................................................................................................................ 7-48
Default Dynamic Task Items .................................................................................................. 7-51
In-Context Launch of Dynamic Task Items ......................................................................... 7-51
Report Adapters ....................................................................................................................... 7-52
8 Functional Design
Functional Features and Assumptions................................................................................................. 8-1
Overview: What Does Oracle Retail Allocation Do? .................................................................... 8-1
Item Sources................................................................................................................................. 8-2
How Need is Determined .......................................................................................................... 8-3
'What if' On Hand ....................................................................................................................... 8-4
Purchase Order Addition........................................................................................................... 8-4
Holdback Quantity ..................................................................................................................... 8-4
Allocation Approval Process..................................................................................................... 8-6
Functional Assumptions ................................................................................................................... 8-6
Advanced Shipping Notice-Based Allocation Assumptions................................................ 8-6
Item-location Assumptions ....................................................................................................... 8-6
Calculation Multiple Assumptions .......................................................................................... 8-6
What if .......................................................................................................................................... 8-6
Weight and Date User Selection Assumptions....................................................................... 8-7
Proportional Allocation Assumption....................................................................................... 8-7
Scheduled Allocation Constraints ................................................................................................... 8-7
Batch Job Considerations for Scheduled Allocations ............................................................ 8-8
Additional Validations for Scheduled Allocation.................................................................. 8-8
Allocation Status ................................................................................................................................ 8-9
Allocation Process Status ........................................................................................................ 8-10
Sources of Data Used by Rules to Determine Gross Need........................................................ 8-11
History Data Sources ............................................................................................................... 8-12
Forecast Data Sources.............................................................................................................. 8-12
Plan Data Sources..................................................................................................................... 8-12
Receipt Plan Data Sources ...................................................................................................... 8-12
History and Plan Data Sources .............................................................................................. 8-13
Plan Re-project Data Sources ................................................................................................. 8-13
Corporate Rules........................................................................................................................ 8-14
Quantity Limits ........................................................................................................................ 8-14
Net Need at Store Level Calculation ..................................................................................... 8-14
Closing Allocations ......................................................................................................................... 8-15
viii
9 Functional and Technical Integration
Integration Interface Allocation-Related Dataflow........................................................................... 9-1
From Oracle Retail Demand Forecasting System to Oracle Retail Allocation via Merchandising
System 9-2
From Oracle Retail Planning Application to Oracle Retail Allocation....................................... 9-3
From Size Profile Optimization to Oracle Retail Allocation........................................................ 9-3
From Retail Demand Forecasting/Curve to Oracle Retail Allocation ....................................... 9-4
From Oracle Retail Warehouse Management System to Oracle Retail Allocation via Oracle
Retail Merchandising System 9-4
From Oracle Retail Promotion Management to Oracle Retail Allocation ................................. 9-4
From Oracle Retail Merchandising System to Oracle Retail Allocation .................................... 9-4
From Oracle Retail Allocation to Oracle Retail Merchandising System .................................... 9-4
From Oracle Retail Merchandising System to Oracle Retail Warehouse Management System ....
9-5
From Oracle Retail Active Retail Intelligence to Oracle Retail Allocation ................................ 9-5
Persistence Layer Integration................................................................................................................. 9-5
Persistence Layer Integration (Including Tables and Triggers) .................................................. 9-5
Oracle Retail Merchandising System Functional Dependencies and Assumptions ............... 9-10
Oracle Retail Merchandising System Differentiator Setup ....................................................... 9-10
Staple Item........................................................................................................................................ 9-11
Pack Item .......................................................................................................................................... 9-12
Summary of Items and How Oracle Retail Allocation Handles Them ................................... 9-12
Oracle Retail Allocation Functional Assumptions Related to Oracle Retail Merchandising
System 9-13
10 Oracle Retail Extract, Transform, and Load (RETL) Batch Processing

Functional Overview ............................................................................................................................ 10-1
Oracle Retail Extract, Transform, and Load Batch Processing Architecture.............................. 10-2
Processing Stage 1 ........................................................................................................................... 10-2
Processing Stage 2 ........................................................................................................................... 10-3
Configuration................................................................................................................................... 10-3
Oracle Retail Extract, Transform, and Load......................................................................... 10-3
Oracle Retail Extract, Transform, and Load User and Permissions ................................. 10-3
Environment Variables ........................................................................................................... 10-3
alc_config.env Settings ............................................................................................................ 10-4
Running the Module....................................................................................................................... 10-4
Schema File ............................................................................................................................... 10-4
Mandatory Multi-Threading and Command Line Parameters......................................... 10-4
Business Virtual Date .............................................................................................................. 10-5
Program Return Code ............................................................................................................. 10-5
Program Status Control Files ................................................................................................. 10-5
Oracle Retail Allocation Oracle Retail Extract, Transform, and Load Restart and Recovery..
10-6
Message Logging ..................................................................................................................... 10-6
Program Error File ................................................................................................................... 10-7
Oracle Retail Allocation Reject Files...................................................................................... 10-7
Typical Run and Debugging Situations....................................................................................... 10-8
ix
Example for Running Load Batch ......................................................................................... 10-9
Oracle Retail Allocation Program Reference............................................................................... 10-9
Application Programming Interface (API) Specification ........................................................ 10-13
File Layout .............................................................................................................................. 10-13
Oracle Retail Extract, Transform, and Load for Receipt and Plan ........................................ 10-18
Oracle Retail Extract, Transform, and Load for Size Profile Optimization Data................. 10-18
Limitations of Oracle Retail Extract, Transform, and Load Programs ................................. 10-19
11 Java Batch Process

Batch Processing Overview ................................................................................................................. 11-1
Java Batch Names and Java Packages .......................................................................................... 11-1
Running a Java-based Batch Process ............................................................................................ 11-2
Scheduler and Command Line...................................................................................................... 11-2
Running the Dashboard Refresh Batch................................................................................. 11-2
Running the Schedule Allocation Batch ............................................................................... 11-2
Running the Daily Cleanup Batch ......................................................................................... 11-3
Running the Purge Batches .................................................................................................... 11-4
Running the Rule Level On Hand Batch .............................................................................. 11-4
Summary of Executable Files ........................................................................................................ 11-4
AllocScheduleBatch Process Batch Design ...................................................................................... 11-5
Usage................................................................................................................................................. 11-5
Detail ................................................................................................................................................. 11-5
Log File ............................................................................................................................................. 11-5
Properties File .................................................................................................................................. 11-6
Configuration................................................................................................................................... 11-6
Assumptions and Scheduling Notes ............................................................................................ 11-6
AlcDailyCleanUp Process Batch Design .......................................................................................... 11-6
Usage................................................................................................................................................. 11-6
Detail ................................................................................................................................................. 11-6
AlcPurgeAlloc AlcPurgeWksht Batch Processes Design............................................................... 11-7
Usage................................................................................................................................................. 11-8
Details: .............................................................................................................................................. 11-8
Rule Level On Hand Pre-Aggregation Inventory Snapshot Batch Design................................ 11-8
Usage................................................................................................................................................. 11-8
Detail ................................................................................................................................................. 11-9
Package Details.............................................................................................................................. 11-10
Implementation ............................................................................................................................. 11-11
12 Internationalization
Translation.............................................................................................................................................. 12-1
Setting the User Language .................................................................................................................. 12-2
Setting Date, Time, and Number Formats ....................................................................................... 12-2
Translations ............................................................................................................................................ 12-2
13 Implementing Functional Security

Access Oracle Enterprise Manager Fusion Middleware Control................................................. 13-1
x
Displaying the Security Menu....................................................................................................... 13-1
Managing Role Hierarchy.................................................................................................................... 13-4
Adding or Removing Members from an Application Role ...................................................... 13-4
Creating Job Roles ................................................................................................................................ 13-7
Creating Duty Roles ............................................................................................................................. 13-7
Creating a New Application Role................................................................................................. 13-7
Creating an Application Role from an Existing Role................................................................. 13-8
Security in Retail Applications........................................................................................................... 13-9
Single Sign On (SSO) Setup for Retail Fusion Platform Applications..................................... 13-9
Displaying External Application Contents in Non-SSO Environments ............................... 13-10
xi
xii
Send Us Your Comments
Oracle welcomes customers' comments and suggestions on the quality and usefulness
of this document.
Your feedback is important, and helps us to best meet your needs as a user of our
products. For example:
■ Are the implementation steps correct and complete?
■ Did you understand the context of the procedures?
■ Did you find any errors in the information?
■ Does the structure of the information help you with your tasks?
■ Do you need different information or graphics? If so, where, and in what format?
■ Are the examples correct? Do you need more examples?
If you find any errors or have any other suggestions for improvement, then please tell
us your name, the name of the company who has licensed our products, the title and
part number of the documentation and the chapter, section, and page number (if
available).
Note: Before sending us your comments, you might like to check

that you have the latest version of the document and if any concerns
are already addressed. To do this, access the Online Documentation
available on the Oracle Technology Network Web site. It contains the
most current Documentation Library plus all documents revised or
released recently.
Send your comments to us using the electronic mail address: [email protected]

Please give your name, address, electronic mail address, and telephone number
(optional).
If you need assistance with Oracle software, then please contact your support
representative or Oracle Support Services.
If you require training or instruction in using Oracle software, then please contact your
Oracle local office and inquire about our Oracle University offerings. A list of Oracle
offices is available on our Web site at http://www.oracle.com.
xiii
xiv
Preface
The Oracle Retail Allocation Operations Guide provides critical information about the
processing and operating details of the application, including the following:
■ System configuration settings
■ Technical architecture
■ Functional integration dataflow across the enterprise
■ Batch processing
Audience
This guide is for:
■ Systems administration and operations personnel
■ Systems analysts
■ Integrators and implementation personnel
■ Business analysts who need information about product processes and interfaces
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support

Oracle customers that have purchased support have access to electronic support
through My Oracle Support. For information, visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are
hearing impaired.
Related Documents
For more information, see the following documents in the Oracle Retail Allocation
documentation set:
■ Oracle Retail Allocation Release Notes
■ Oracle Retail Allocation Installation Guide
xv
■ Oracle Retail Allocation User Guide and Online Help
■ Oracle Retail Allocation Data Model
■ Oracle Retail Merchandising Implementation Guide
■ Oracle Retail Merchandising Security Guide
■ Oracle Retail Merchandising Batch Schedule
■ Oracle Retail Operational Insights User Guide
Customer Support
To contact Oracle Customer Support, access My Oracle Support at the following URL:
https://support.oracle.com
When contacting Customer Support, please provide the following:

■ Product version and program/module name
■ Functional and technical description of the problem (include business impact)
■ Detailed step-by-step instructions to re-create
■ Exact error message received
■ Screen shots of each step you take
Review Patch Documentation

When you install the application for the first time, you install either a base release (for
example, 16.0) or a later patch release (for example, 16.0.1). If you are installing the
base release and additional patch releases, read the documentation for all releases that
have occurred since the base release before you begin installation. Documentation for
patch releases can contain critical information related to the base release, as well as
information about code changes since the base release.
Improved Process for Oracle Retail Documentation Corrections

To more quickly address critical corrections to Oracle Retail documentation content,
Oracle Retail documentation may be republished whenever a critical correction is
needed. For critical corrections, the republication of an Oracle Retail document may at
times not be attached to a numbered software release; instead, the Oracle Retail
document will simply be replaced on the Oracle Technology Network Web site, or, in
the case of Data Models, to the applicable My Oracle Support Documentation
container where they reside.
This process will prevent delays in making critical corrections available to customers.
For the customer, it means that before you begin installation, you must verify that you
have the most recent version of the Oracle Retail documentation set. Oracle Retail
documentation is available on the Oracle Technology Network at the following URL:
http://www.oracle.com/technetwork/documentation/oracle-retail-100266.ht
ml
An updated version of the applicable Oracle Retail document is indicated by Oracle

part number, as well as print date (month and year). An updated version uses the
same part number, with a higher-numbered suffix. For example, part number
E123456-02 is an updated version of a document with part number E123456-01.
xvi
If a more recent version of a document is available, that version supersedes all
previous versions.
Oracle Retail Documentation on the Oracle Technology Network

Oracle Retail product documentation is available on the following web site:
http://www.oracle.com/technetwork/documentation/oracle-retail-100266.ht
ml
(Data Model documents are not available through Oracle Technology Network. You
can obtain these documents through My Oracle Support.)
Conventions
The following text conventions are used in this document:
Convention Meaning
boldface Boldface type indicates graphical user interface elements associated
with an action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for
which you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code
in examples, text that appears on the screen, or text that you enter.
xvii
xviii
1
Introduction
1
Welcome to the Oracle Retail Allocation Operations Guide. The guide is designed so
that you can view and understand key system-administered functions, the flow of data
into and out of the application, and the application's behind-the-scenes processing of
data.
Allocation Overview
A retailer that acquires Oracle Retail Allocation gains the ability to achieve more
accurate allocations on a stable product. Having the right product in the right stores or
warehouses allows for service levels to be raised, sales to be increased, and inventory
costs to be lowered. By accurately determining which locations should get which
product, retailers can meet their turnover goals and increase profitability.
The Oracle Retail Allocation retailer benefits from the following capabilities:
■ Built on ADF Technology stack, it allows the ability to quickly add UI based on
ready to use design patterns, metadata driven tools and visual tools. Debugging
can be performed more rapidly; maintenance and alteration costs are kept low
using the metadata driven application development.
■ The application's interface takes advantage of the Java Database Connectivity
(JDBC), ADF's built-in transaction management, along with connections to data
sources handled in WebLogic server which minimizes the interface points that
need to be maintained.
■ The application's robust algorithm executes rapidly, and the call to the calculation
engine has been ported over from C++ library to a Java Library, thus minimizing
the overhead/issues related to maintaining codebase consisting of two disparate
languages.
■ For retailers with other Oracle Retail products, integration with the Oracle Retail
product suite means that item, purchase order, supplier, sales, and other data are
accessed directly from the RMS tables, with no need for batch modules. Purchase
order, item, location, and allocation information are passed from RMS to a
warehouse management system, such as the Oracle Retail Warehouse
Management System (RWMS).
■ Access control to the system is better managed by using Fusion Security
Architecture.
■ The application allows for retailers to adjust to changing trends in the market by
facilitating real time allocations.
■ Oracle Retail Allocation accounts for flexible supply chain paths to support
importing and domestic inventory supply.
Introduction 1-1
Allocation Overview
The following diagram illustrates the Allocation n-tier architecture:
Figure 1–1 Oracle Retail Allocation's n-tier Architecture
RMS owns virtually all of the information that Oracle Retail Allocation needs to
operate, and the information that Oracle Retail Allocation provides is of primary
interest/use for RMS. As a result, Oracle Retail Allocation has limited interaction with
other Oracle Retail Merchandising Operations Management applications. For Oracle
Retail Merchandising Operations Management applications that Oracle Retail
Allocation does interact with, it is managed through direct reads from Oracle Retail
Merchandising Operations Management application tables, direct calls to Oracle Retail
Merchandising Operations Management packages, and Oracle Retail Allocation
packages based on Oracle Retail Merchandising Operations Management application
tables.
1-2 Oracle® Retail Allocation Operations Guide

2
Technical Architecture
2
This chapter describes the overall software architecture for Oracle Retail Allocation.
The chapter provides a high-level discussion of the general structure of the system,
including the various layers of Java code.
Overview
Retail Applications are based on the Oracle Application Development Framework
(ADF). The following diagram shows the key components that make up the
architecture of Retail Applications.
Figure 2–1 Oracle Retail Allocation's n-tier Architecture
Oracle Application Development Framework (ADF)

Oracle Application Development Framework (ADF) supports organizations in
building cutting-edge rich enterprise business applications that can be customized and
personalized in all dimensions. Customizations are global changes, visible to all users
that are performed by an administrator. Personalizations are user-made changes that
are only visible to the person making the change.
ADF is based on the Java Enterprise Edition platform.
Technical Architecture 2-1

Overview
Model-View-Controller (MVC) Architectural Pattern

Applications built using ADF follow a Model-View-Controller (MVC) architectural
pattern. The goal of the MVC pattern is to clearly separate the application's
functionality into a set of cooperating components.
ADF provides a set of components that realize the goals of each part of MVC pattern.
■ Model is realized by the ADF Bindings Layer.
■ Controller is realized by the ADF Controller Layer.
■ View is realized by the ADF Faces Layer.
■ ADF Business components and other backend components that sit below the
Model layer are called Business Services.
Application Development Framework Security

The ADF security layer provides the following:
■ Standards based (Oracle Platform Security Services (OPSS)) security framework
with default roles and permissions.
■ Tools to generate file-based identity store (for both Oracle Internet Directory and
AD) based on the framework.
■ Tools to migrate file-based security store in to database for QA and production
environments.
■ Reference implementation for clients to manage the security based on their
business needs.
■ OPSS-based batch security framework (Retail Fusion Platform).
■ Tools/documentation to implement centralized logout in Single Sign-On (SSO)
(Oracle Access Management (OAM)) environments.
Application Development Framework View (ADFv)

The View layer provides the user interface to the application. The view layer uses
HTML, rich Java components or XML and its variations to render the user interface.
JSF based tag libraries are used to display the User Interface (UI).
Application Development Framework Controller (ADFc)

The ADF Controller layer controls the application's flow. Web based applications are
composed of multiple web pages with dynamic content. The controller layer manages
the flow between these pages. Different models can be used when building this later.
The most prominent architecture for Java-based web applications relies on a servlet
that acts as the controller. The Apache Jakarta Struts controller, an open source
framework controller, is the de facto standard for Java-based web systems. Oracle ADF
uses the Struts controller to manage the flow of web applications.
Application Development Framework Business Components (ADFbc)

The business service layer manages the interaction with a data persistence layer. It
provides services as data persistence, object/relational mapping, transaction
management, and business logic execution.
Business Components easily map the database object and extend it with business logic,
validation, and so on.
The idea behind Business Components is to abstract the data layer from the view layer.
This is a key concept in the MVC pattern. Business Components expose the interface to

Overview
the view layer by using an application module that contains View Object. Those view
objects contain a specific usage of the data layer.
ADF Business Components implements the business service through the following set
of cooperating components:
■ Entity object – An entity object represents a row in a database table and simplifies
modifying its data by handling all data manipulation language (DML) operations
for you. It can encapsulate business logic for the row to ensure that your business
rules are consistently enforced. You associate an entity object with others to reflect
relationships in the underlying database schema to create a layer of business
domain objects to reuse in multiple applications.
■ View object – A view object represents a SQL query. You use the full power of the
familiar SQL language to join, filter, sort, and aggregate data into exactly the shape
required by the end-user task. This includes the ability to link a view object with
others to create master-detail hierarchies of any complexity. When end users
modify data in the user interface, view objects collaborate with entity objects to
consistently validate and save the changes.
■ Application module – An application module is the transactional component that
UI clients use to work with application data. It defines an updatable data model
and top-level procedures and functions (called service methods) related to a
logical unit of work related to an end-user task.
Application Development Framework Model (ADFm)

This is the component that acts as the connector between the view and business logic
layers.
The Model layer connects the Business Services to the objects that use them in the
other layers. Oracle ADF provides a Model layer implementation that sits on top of
Business Services, providing a single interface that can be used to access any type of
Business Services.
Developers get the same development experience when binding any type of Business
Service layer implementation to the view and Controller layers. The Model layer in
Oracle ADF served as the basis for JSR 227, A Standard Data binding & Data Access
Facility for J2EE.
Oracle Metadata Services (MDS)

The ability of an application to adapt to changes is a necessity that needs to be
considered in the application design and that should drive the selection of the
development platform and architecture. Flexible business applications must be able to
adapt to organizational changes, different end user preferences and changes in the
supported business are required.
MDS is the customization and personalization framework integral to Oracle Fusion
Middleware and a key differentiator of the Oracle development platform. MDS
provides a repository for storing metadata for applications, such as customizations
and persisted personalization files and configurations.
Retail applications allow the following through MDS:
■ Personalization of saved searches through MDS.
■ Implicit personalization of few ADF UI attributes.
Technical Architecture 2-3

Overview
Retail Fusion Platform

The Retail Fusion Platform (commonly referred to as Platform) is a collection of
common, reusable software components that serve as foundation for building Oracle
Retail's next generation ADF-based applications. The Platform imposes standards and
patterns along with a consistent look and feel for Oracle Retail's ADF applications.
Allocation Backend Service

Allocation Backend Service is collective Business Legacy components that are reused
in the new ADF Version of Allocation.
Data Access Patterns

Database interaction between the middle tier and the database is done using the
industry standard Java Database Connectivity Protocol (JDBC). JDBC facilitates the
communication between a Java application and a relational database.
Database Access Using ADFbc

JDBC is ingrained within Oracle ADF Business Components as the primary
mechanism for its interaction between the middle tier and the database. SQL is
realized within ADF business components to facilitate create, read, update and delete
(CRUD) actions.
Connection Pooling
When the application 'disconnects' a connection, the connection is saved into a pool
instead of being actually disconnected. A standard connection pooling technique, this
saved connection, enables Retail applications to reuse the existing connection from a
pool. In other words, the application does not have to complete the connection process
for each subsequent connection.
Data Storage
The Oracle database realizes the database tier in a Retail application’s architecture. It is
the application's storage platform, containing the physical data (user and system) used
throughout the application. The database tier is only intended to handle the storage
and retrieval of information and is not involved in the manipulation or in the delivery
of the data. This tier responds to queries; it does not initiate them.
Accessing Merchandising System Data in Real Time

The data that the Retail application utilizes is located in both the application-specific
and the merchandising system (RMS, for example) tables. Because Retail applications
share the same schema as the merchandising system (RMS, for example), the
application is able to interact with the merchandising system's data directly, in real
time.

3
Back-end System Administration and
3
Configuration
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.
Managing Asynchronous Processes

This section covers the following topics:
■ Overview of Asynchronous Processes in Retail Applications
■ Configuring JMS Resources for Asynchronous Processing
■ Monitoring Asynchronous Tasks Via the RAF_ASYNC_TASK Table
■ Purging the Asynchronous Tasks Table
Overview of Asynchronous Processes in Retail Applications

Applications may need to execute operations that can take significant time to
complete.
Executing these operations in the application's own thread will cause the application
to block other operations until those long-running operations finish.
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 using Java Messaging Service
(JMS). When a user, for instance, through the application UI screen, submits a business
entity for processing asynchronously, the application goes through a process depicted
in the diagram below:
Back-end System Administration and Configuration 3-1

Figure 3–1 Asynchronous Process
1. 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.
2. The producer method creates a queue message and sends it to a JMS Queue.
3. One or more instances of Message Driven Beans (MDB) are configured to listen
to the JMS Queue.
4. 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.
5. The MDB executes the required processing for the task.
Configuring JMS Resources for Asynchronous Processing

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 3–1 WebLogic Administrator Console Resources

WebLogic Server Required
Resource Names/References Configuration Notes
JMS Server Any name can be None. Defaults provided by WebLogic
used. acceptable.
JMS Module Any name can be None. Defaults provided by WebLogic
used. acceptable.
JMS Queue Name: ■ Create the queue under the JMS Module.
calcQueue ■ Associate a sub-deployment for the
queue. If none exists, create it. The
sub-deployment must be the same as the
JNDI: JMS Queue Connection Factory's.
oracle.retail.apps.alc.a ■ Redelivery Limit must be set to zero (0).
sync.AllocCalcQueue
■ Error Destination must be set to NONE.

Table 3–1 (Cont.) WebLogic Administrator Console Resources

WebLogic Server Required
Resource Names/References Configuration Notes
JMS Queue Name: ■ Create under the same JMS Module as the
Connection Factory queue.
allocCalcQueueCF
■ Associate a sub-deployment for the queue
connection factory. If none exists, create it.
JNDI: The sub-deployment must be the same as
the JMS Queue's.
oracle.retail.apps.alc.a
sync.AllocCalcQueue ■ Maximum Messages per Session must be
CF set to one (1).
■ XA Connection Factory Enabled must be
true.
Work Manager Name: ■ Create Minimum and Maximum Thread
Constraints and assign to the work
AllocWorkManager
manager.
- The recommended Minimum Thread
Constraint is 8.
- The Maximum Thread Constraint must
be set. Typically, it should be set to the
maximum number of anticipated
application users on the system at any
given time.
■ Associate the work manager to the Retail
Application asynchronous consumer
MDB,AllocConsumerMDBBean, by
specifying the work manager name in the
MDB's Dispatch Policy field.
Refer to WebLogic documentation found in

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.
html.
for detailed information about how to configure the above resources.
Monitoring Asynchronous Tasks Via the RAF_ASYNC_TASK Table

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 3–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_ A code representing the Retail Application that generated the
CODE asynchronous task.
TASK_DESC A short description of the asynchronous task.

Table 3–2 (Cont.) RAF_ASYNC_TASK Table Details

RAF_ASYNC_
TASK Column Description
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.
■ NEW - The task is ready to be asynchronously processed.
■ IN-PROGRESS - The task is currently being processed by the
application.
■ SUCCESS - Processing for the task completed successful.
■ FAILED - Processing for the task completed with failures.
Additional information about the failure can be found in the
PROCESS_ERROR_TXT column and/or the server logs.
TASK_ A fully-qualified Java class name that contains the business logic for
COMMAND_ completing the task.
CLASS_NAME
PUBLISH_ The time and date when the asynchronous task was published. That
TIMESTAMP is, when the status was changed to NEW.
PROCESS_START_ The time and date when processing of the asynchronous task started.
TIMESTAMP That is, when the status was changed to IN-PROGRESS.
PROCESS_END_ The time and date when the processing of the asynchronous task
TIMESTAMP ended with either a SUCCESS or FAILED status.
PROCESS_ When the status is FAILED, this column would contain information
ERROR_TXT 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_ Audit field pertaining to the user that last updated the row.
BY
LAST_UPDATE_ Audit field pertaining to the last date/time when the row was
DATE updated.
Purging the Asynchronous Tasks Table

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 retailers 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).
declare
retval number(10);
begin
-- remove rows older than 5 days
retval := raf_async_task_pkg.delete_async_task(5);
end;
/

Managing the Notifications Feature

■ Overview of Notifications in Retail Applications
■ Purging the Notifications Table
Overview of Notifications in Retail Applications

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, the user is expected to take action on these
notifications.
The notification icon on the Retail Application's navigation pane displays the count of
unread notifications for the user. When a notification is generated, this count is
incremented immediately and thereafter refreshed at regular configurable intervals.
The sliding sidebar menu expands when the user clicks on the notification icon. The
expanded sidebar menu will show the latest notifications. Clicking on "See All" will
show all the notifications in a new tab.
Clicking on the link for each launchable notification opens the specific UI flow that
will allow the user to address any pending action for the notification.
Figure 3–2 Sliding Sidebar showing the Notification Count

Figure 3–3 Notifications Sidebar Menu
Purging the Notifications Table

Notifications are represented as rows in the table RAF_NOTIFICATION. Over a
period of time, depending on how notifications are being generated by the application,
the size of this table can grow continually, potentially degrading performance of the
notifications feature.
It is recommended that retailers purge this table periodically. You can do this via the
Purge feature available in the Retail Application Administration Console (RAAC). For
more details on the Manage Notifications feature in RAAC, please refer to the Oracle
Retail Application Administration Console User Guide.
You could also setup a batch job that runs periodically, that invokes the pl-sql as
shown below:
declare
retval number(10);
begin
-- remove Notifications from the Allocation application that have exceeded . --
their retention duration.
retval := raf_notification_task_pkg. DEL_NOTIF_PAST_RETENTION('ALC');
end;

Notification ReST Services

ReST Endpoints have been exposed by the Notifications framework to ease the
integration concerns with disparate applications.
Enabling Mobile Push Notifications

Users of the mobile version of the Retail Application can receive notifications in their
mobile devices using push notifications.
Push notifications for Mobile Retail Applications need to be enabled by the Retailer.
This section describes the specific steps to enable this feature.
Note that push notification is a native feature in modern mobile devices so the steps to
enable this service on different platforms will be different.
Prerequisite: Apple Certificate and Provisioning Profile

Using push notifications on iOS requires retailers to acquire an Apple Push
Notification (APN) Service key, certificate and Provisioning profile. These files are
specific to the application and are linked to the developer account that Apple
generated them from. Refer to Apple's developer site for instructions on how to create
an account and generate these credentials.
Prerequisite: Android Google Cloud Messaging Registration

Using push notifications on Android requires retailers to register the mobile Retail
Application with Google Cloud Messaging (GCM). An API key and sender ID will be
generated from the account created during registration. Refer to Google's developer
site for instructions on how to create an account and generate these credentials.
Server Configuration
Once credentials to the specific platforms are available, retailers need to add these to
the server.
For Apple Push Notifications, retailers must import the key and certificate from Apple
into weblogic. In order to do this, a keystore (JKS) file must be created using the Java
keystore utility. The key and certificate can then be imported into the created keystore
file. Retailers can refer to Oracle Java SE documentation for details on the keystore
utility.
Once created, the keystore can be uploaded into the weblogic system app stripe.
Retailers can use the weblogic scripting tool to run a Python script similar to the one
shown below. The example shows that the keystore is named RetailAppsPushServices.
user = "admin username"
password = "admin password"
url = "[weblogic server]:[port]"
keypass = "keystore password"
keypath = "keystore filepath"
apnsAlias = "key alias"
apnsPass = "key password"
connect(user, password, url)
svc = getOpssService(name='KeyStoreService')
svc.importKeyStore(appStripe='system', name='RetailAppsPushServices', type='JKS',
filepath=keypath, password=keypass, permission=true, aliases=apnsAlias,
keypasswords=apnsPass)
exit('y')
For more details on how to import the created java keystores into WebLogic, refer to
Oracle WebLogic Server and Oracle Fusion Middleware documentation.

Managing Application Navigator
For Android notifications, retailers will need to set up the acquired API key as a
generic credential in WebLogic. The GCM API key must be set in a map named
"RetailAppsPushServices" under the key "gcmApiKey". Refer to Oracle WebLogic
Server and Oracle Fusion Middleware documentation for instructions on creating and
setting generic credentials
Lastly, if the server environment has proxy settings, the RetailAppsPushServices
deployed on the weblogic server has to be modified. Retrieve the
RetailAppsPushServices application enterprise archive (EAR) from the server, and
modify the proxy.properties within. Once completed, the modified EAR file has to be
redployed to the server.
Managing Application Navigator

Retail Applications provide an ability to switch between applications using the
Application Navigator facility. These applications are configured using the Manage
Application Navigator screens on Retail Application Administration Console (RAAC).
For more details on Application Navigator in RAAC, please refer to the Oracle Retail
Merchandising Implementation Guide.
Managing Functional Security

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, refer to the Oracle Fusion Middleware Application Security Guide.
■ Introduction to Retail Roles
■ Retail Role Hierarchy
■ Default Security Reference Implementation
■ Extending the Default Security Reference Implementation
Introduction to Retail Roles

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.
Security Policy Stripe

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
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
Job roles are associated with the job of a user. A user 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.
Duty Roles
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 Roles
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 Hierarchy

Retail role hierarchies are structured to reflect the Retail business process model.
Figure 3–4 Retail Role Hierarchy
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>
<members>
<member>
<class>oracle.security.jps.internal.core.principals.
JpsXmlEnterpriseRoleImpl</class>
<name>BUYER_JOB</name>
</member>
<member>

<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>
<members>
<member>
<name>ALC_ALLOC_SIZE_PROFILE_INQUIRY_DUTY</name>
</member>
</members>
</app-role>
Default Security Reference Implementation

Retail applications ship with default security reference implementations. The source of
truth for default reference implementation is the jazn-data.xml file.
Privileges
For more information on privileges, see Default Security Reference Implementation in
the Implementing Functional Security chapter.
Table 3–3 Privileges

Name Description
ALC_ALLOC_SEARCH_ A privilege for searching for allocations.
PRIV
ALC_ALLOC_VIEW_PRIV Privilege for Viewing the Allocation.
ALC_ALLOC_MAINTAIN_ Privilege for Create and Edit Allocation.
PRIV
ALC_ALLOC_DELETE_ Privilege for Deleting Allocation.
PRIV
ALC_ALLOC_POLICY_ Privilege for Searching Policy Template
MAINTENANCE_
SEARCH_PRIV
ALC_ALLOC_POLICY_ Privilege for Create and Edit Policy Template
MAINTENANCE_
MAINTAIN_PRIV
ALC_ALLOC_POLICY_ Privilege for Viewing the Policy Template.
MAINTENANCE_VIEW_
PRIV
ALC_ALLOC_POLICY_ Privilege for Deleting Policy Template.
MAINTENANCE_
DELETE_PRIV
ALC_ALLOC_LOC_ Privilege for Searching Allocation Location Group.
GROUPS_SEARCH_PRIV

Table 3–3 (Cont.) Privileges

Name Description
ALC_ALLOC_LOC_ Privilege for Create and Edit Allocation Location Group.
GROUPS_MAINTAIN_
PRIV
ALC_ALLOC_LOC_ Privilege for Viewing the Allocation Location Group.
GROUPS_VIEW_PRIV
ALC_ALLOC_LOC_ Privilege for Delete Allocation Location Group.
GROUPS_DELETE_PRIV
ALC_ALLOC_SIZE_ Privilege for Search Size Profile.
PROFILE_SEARCH_PRIV
ALC_ALLOC_SIZE_ Privilege Create and Edit Size Profile.
PROFILE_MAINTAIN_
PRIV
ALC_ALLOC_SIZE_ Privilege for Viewing the Size profile.
PROFILE_VIEW_PRIV
ALC_ALLOC_SIZE_ Privilege for Deleting the Size Profle.
PROFILE_DELETE_PRIV
ALC_ALLOC_SUBMIT_ Privilege for Submitting the Allocation.
PRIV
ALC_ALLOC_SYSTEM_ Privilege for Edit the System Options.
OPTIONS_SYSTEM_
PROPERTIES_MAINTAIN_
PRIV
ALC_ALLOC_SYSTEM_ Privilege for Viewing the System Options.
OPTIONS_VIEW_PRIV
ALC_DASHBOARD_PRIV Privilege for Viewing the Dashboard.
ALC_ALLOC_AUTO_ Privilege for Searching Auto Quantity Limits.
QUANTITY_LIMITS_
SEARCH_PRIV
ALC_ALLOC_AUTO_ Privilege for Create and Edit Auto Quantity Limits.
QUANTITY_LIMITS_
MAINTAIN_PRIV
ALC_ALLOC_AUTO_ Privilege for Viewing the Auto Quantity Limits.
QUANTITY_LIMITS_
VIEW_PRIV
ALC_ALLOC_AUTO_ Privilege for Deleting the Auto Quantity Limits.
QUANTITY_LIMITS_
DELETE_PRIV
Duties
For more information on duties, see Default Security Reference Implementation in the
Implementing Functional Security chapter.

Table 3–4 Duties

Name Description List of Privileges
Allocation A duty for ■ All privileges found in the Allocation Inquiry
Managemen managing Duty
t Duty allocations. This
■ Maintain Allocation Privilege
duty is an
extension of the ■ Delete Allocation Privilege
Allocation
Inquiry Duty.
ALC_ A duty for ■ ALC_ALLOC_POLICY_MAINTENANCE_
ALLOC_ Managing the SEARCH_PRIV
POLICY_ Policy Template
■ ALC_ALLOC_POLICY_MAINTENANCE_
MAINTEN
VIEW_PRIV
ANCE_
MANAGEM ■ ALC_ALLOC_POLICY_MAINTENANCE_
ENT_DUTY MAINTAIN_PRIV
■ ALC_ALLOC_POLICY_MAINTENANCE_
DELETE_PRIV
ALC_ A duty for ■ ALC_ALLOC_SIZE_PROFILE_DELETE_PRIV
ALLOC_ Managing the
■ ALC_ALLOC_SIZE_PROFILE_SEARCH_PRIV
SIZE_ Size Profile
PROFILE_ ■ ALC_ALLOC_SIZE_PROFILE_VIEW_PRIV
MANAGEM
■ ALC_ALLOC_SIZE_PROFILE_MAINTAIN_
ENT_DUTY
PRIV
ALC_ A duty for ■ ALC_ALLOC_LOC_GROUPS_DELETE_PRIV
ALLOC_ Managing the
■ ALC_ALLOC_LOC_GROUPS_VIEW_PRIV
LOC_ Allocation
GROUPS_ Location Group ■ ALC_ALLOC_LOC_GROUPS_MAINTAIN_
MANAGEM PRIV
ENT_DUTY
■ ALC_ALLOC_LOC_GROUPS_SEARCH_DUTY
ALC_ A duty for ■ ALC_ALLOC_AUTO_QUANTITY_LIMITS_
ALLOC_ Managing the DELETE_PRIV
AUTO_ Auto Quantity
■ ALC_ALLOC_AUTO_QUANTITY_LIMITS_
QUANTITY Limits
SEARCH_PRIV
_LIMITS_
MANAGEM ■ ALC_ALLOC_AUTO_QUANTITY_LIMITS_
ENT_DUTY VIEW_PRIV
■ ALC_ALLOC_AUTO_QUANTITY_LIMITS_
MAINTAIN_PRIV
ALC_ A duty for ALC_ALLOC_SUBMIT_PRIV
ALLOC_ Reserve and
SUBMIT_ Approve
DUTY Allocation
ALC_ A duty for ALC_DASHBOARD_PRIV
DASHBOA Viewing the
RD_DUTY Dashboard.
Role Mapping
For more information on role mapping, see Default Security Reference Implementation
in the Implementing Functional Security chapter.

Table 3–5 Role Mapping

Duty Role
ALC_ALLOC_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
MANAGEMENT_DUTY
■ ALC_ALLOC_SEARCH_PRIV
■ ALLOCATOR_JOB
ALC_ALLOC_POLICY_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
MAINTENANCE_
MANAGEMENT_DUTY
■ ALLOCATOR_JOB
ALC_ALLOC_SIZE_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
PROFILE_
MANAGEMENT_DUTY
■ ALLOCATOR_JOB
ALC_ALLOC_SUBMIT_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
DUTY
ALC_ALLOC_SYSTEM_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
OPTIONS_SYSTEM_
PROPERTIES_
MANAGEMENT_DUTY
ALC_ALLOC_AUTO_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
QUANTITY_LIMITS_
MANAGEMENT_DUTY
■ ALLOCATOR_JOB
ALC_ALLOC_LOC_ ■ ALLOCATION_APPLICATION_ADMINISTRATOR_JOB
GROUPS_
MANAGEMENT_DUTY
■ ALLOCATOR_JOB
Extending the Default Security Reference Implementation
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?

Figure 3–5 Decisions for Default 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.
Managing Roles in Retail Application Administration Console

Retail applications provide a way in which retailers can modify the default roles to
map to their security groups through the Retail Application Administration Console
(RAAC).
RAAC is installed along with the Retail Application. Users with proper security
privileges to access RAAC can launch RAAC by clicking on a link from the Retail
Application's global menu.
For more information about using RAAC, refer to the Oracle Retail Application
Administration Console chapter of the Oracle Retail Merchandising Implementation
Guide.

Disabling Content
There are situations where administrators need to disable certain links or the default
content such as Dashboards due to unavailability or other reasons. Retail Applications
provide the flexibility to disable such content so that the application remains largely
unaffected.
Safe Mode
Applications can choose to serve certain content such as dashboards to users upon
launching the application. This is referred to as "Default Content". However
sometimes this default content may cause delays in application launch after logging-in
or worse it may render the application unusable.
To handle such scenarios Retail Applications provide a feature for Administrators
called "Safe Mode" which. allows the user to log in without serving up any default
content. Once this mode is turned on, no default content is shown to any user when
the application is launched.
To turn on this mode the property "uishell.load.safe.mode" must be set to true in the
RetailAppsViewController.properties file.
Disabling Links in the Sidebar

Administrators may occasionally need to disable content launchable from links in the
sidebar navigation tree. Retail applications provide the ability to disable such links.
To disable a link the Administrator must first find the "id" of that link as specified in
the SidebarNavigationModel.xml file. This value must then be provided to the
property "uishell.sidebar.invalid.item.ids" within the
RetailAppsViewController.properties file. To disable more than one link, pass in
multiple ids separated by a comma.
Managing Oracle Metadata Services (MDS)

Retail Applications are built using ADF and one of the features within ADF is the
Oracle Metadata Services (MDS) framework which provides a facility for retailers to
customize the applications.
Refer to the document, Oracle Fusion Middleware Fusion Developer's Guide for Oracle
Application Development Framework
(https://docs.oracle.com/middleware/1213/adf/develop/adf-web-customizing-apps
.htm#ADFFD2077), for more information about MDS.
Overview of Oracle Metadata Services

Oracle Metadata Services (MDS) is a key infrastructure component in Oracle Fusion
Middleware. It is the layer through which metadata is loaded, saved, cached, stored,
managed, and customized both by various middleware components and by the
applications built on Fusion Middleware.
The use of MDS in ADF applications, for example, can allow applications to remember
how users like to work, and therefore not require them to set up the application for
every session. This may include, for example, saving of common searches and screen
layouts for every user. This allows making use of the application easier and more
intuitive for the users. MDS provides a foundation that can be leveraged by Oracle
Application Development Framework (ADF) applications to provide such persistent
personalization.

Oracle Metadata Services (MDS) makes use of metadata repositories or partitions. A

Metadata repository or partition contains metadata for Oracle Fusion Middleware
components. It can also contain metadata about the configuration of Oracle Fusion
Middleware and metadata for applications. Oracle Metadata Services (MDS) stores the
customizations in a metadata repository and retrieves them at runtime to merge the
customizations with the base metadata to reveal the customized application.
A common problem when a patch is installed for a Retail Application is that certain
screens would fail to load or UI elements fail to display data properly.
The cause of this issue is commonly attributed to user personalization on screen
elements that are now removed in the patch.
For example, prior to patching the application, users may have saved search criterias
on certain screens as a way to conveniently recall their desired search results whenever
they use the application. Those saved search criterias are persisted by ADF in the MDS
repository. If the patch involves the removal of one of the attributes used in the search
criterias, applying the patch will cause the screens that have those search criterias fail
to load.
The MDS repository is configured in the WebLogic server where the Retail Application
is deployed. The repository is database-based and it is organized or subdivided into
partitions. Retail Applications are deployed with their own partition within the
server's MDS repository.
It is recommended to not delete the MDS partition during the upgrade of the Retail
application, instead use the functions described in this document to resolve any issues
related to MDS.
Using the System MBean Browser and the MDSAppRuntime MBean

For managing MDS Customizations in Retail Fusion Applications, use the Oracle
Enterprise Manager to perform common metadata service tasks such as exporting,
deleting, and importing of MDS Customizations. This can be done in the Oracle
Enterprise Manager using the System MBean Browser and the MDSAppRuntime
MBean.
Perform the following steps to access the MDSAppRuntime MBean.
1. Login to the Oracle Enterprise Manager by navigating to the URL in the following
format:
http://<host>:<port>/em/
2. Click on the WebLogic Domain dropdown under the domain name. Navigate to
System MBean Browser menu item and click on System MBean Browser.
Choose the correct domain based on your installation. The figure below displays
the RAFDomain as the domain name.

Figure 3–6 RAFDomain window
3. Under Application Defined MBeans, locate MDSAppRuntime which can be found

under the following folder structure:
> oracle.mds.lcm
> Server: AppServer
> Application: Application Name
> MDSAppRuntime
Choose the correct server and the Retail Application name based on your
installation. The figure below displays RAFServer and RetailAppsFrameworkTest
application.

Figure 3–7 RAFDomain System MBean Browser window
4. Click MDSAppRuntime management bean (MBean).

Figure 3–8 System MBean Browser
5. Select the Operations tab to view the operations available for the
MDSAppRuntime MBean.
Figure 3–9 MBean Browser Operations Tab
These are the operations which can be used in managing MDS Customizations.
The exportMetadata, deleteMetadata, importMetadata, createMetadataLabel,
listMetadataLabels, deleteMetadataLabel, and promoteMetadataLabel; will be
briefly discussed in the following sections.
Exporting All Metadata Services Customizations

1. Navigate to the MDSAppRuntime management bean (MBean), as described in the
section "Using the System MBean Browser and the MDSAppRuntime MBean".
2. Export metadata by selecting the exportMetadata operation available from the
Operations tab.
3. For toLocation, provide a valid absolute path to a directory or archive in the file
system to which the selected documents will be exported. This location must be
accessible from the machine where the application is running. If it does not exist, a
directory will be created except that when the name ends with ".jar", ".JAR", ".zip",
or ".ZIP", an archive will be created. Exporting metadata to an existing archive will
overwrite the existing file.
Example: /tempDir/downloads/mdsExport/RetailAppsFrameworkTestMDS.zip

4. Click Invoke (located at the upper-right corner of the page) to proceed with the
export operation.
5. Click Return to return to the list of operations.
Exporting Metadata Services Customization for a Specific User

2. Export metadata by selecting the exportMetadata operation available from the
Operations tab.
3. For toLocation, provide a valid absolute path to a directory or archive in the file
system to which the selected documents will be exported. This location must be
accessible from the machine where the application is running. If it does not exist, a
directory will be created except that when the name ends with ".jar", ".JAR", ".zip",
or ".ZIP", an archive will be created. Exporting metadata to an existing archive will
overwrite the existing file.
4. For docs, click the pencil icon. On the Edit Parameter popup, click Add, and in the
Element box, enter a list of comma-separated, fully qualified document names or
document name patterns to export.
To export customizations for a specific page, simply enter the fully qualified base
document name in the Element box.
Example:
/oracle/retail/apps/framework/uishell/skin/page/TestTablesAndTrees.jsff
You can provide the path to multiple documents to export, by clicking the Add
button. Do not provide any docs in case you want to export all customizations for
the user.
5. For restrictCustTo, click the pencil icon. On the Edit Parameter popup, click Add,
and in the Element box, enter the list of customization layer names. This can be a
list of comma-separated customization layer names used to restrict the operation
to only customization documents that match the specified customization layers.
Each customization layer name can contain, within a pair of brackets, optional
customization layer values and value patterns separated by commas. Wildcards
(%) may also be used for restricting the operation.
For example:
Table 3–6 Customization Values

Value Description
user[buyer] Restricts operation to the user ’buyer’
user[buyer, betty_buyer] Restricts operation to the users ’buyer’ and ’betty_buyer’
user[bu%] Restricts operation to user names that start with ’bu’ (for
example, buyer)
user[be%] Restricts operation to user names that start with ’be’ (for
example, betty_buyer)
user[%bu%] Restricts operation to users with ’bu’ in the name (for example,
buyer and betty_buyer)

6. Click Invoke, located at the upper-right corner of the page, to proceed with the
export operation.
7. A confirmation message will display in the page. Click Return to return to the list
of operations.
Deleting All Metadata Services Customizations for a User

2. Delete metadata by selecting the deleteMetadata operation available from the
Operations tab.
document name patterns.
To delete all customizations for a user, enter "/**" (without the quotes).
This will recursively delete all customizations under "/" including any other
customizations located in the folder(s) under it. Click OK.
and in the Element box, enter the list of customization layer names. This can be
used to restrict the operation to only customization documents that match the
specified customization layers.
For example:

Value Description
example, buyer)
delete operation.
of operations.
Deleting a Customization for a Specific Page for All the Users

Operations tab.

3. For excludeBaseDocs, select true. This is a Boolean value indicating whether to

exclude base metadata documents from being deleted.
For example:

Value Description
example, buyer)
delete operation.
of operations.
Deleting a Customization for a Specific Page for a Particular User

Operations tab.
3. For excludeBaseDocs, select true. This is a Boolean value indicating whether to
exclude base metadata documents from being deleted.

For example:

Value Description
example, buyer)
delete operation.
of operations.
Importing All Metadata Services Customizations

2. Import metadata by selecting the importMetadata operation available from the
Operations tab.
3. For fromLocation, enter the path of the directory or archive from which the
documents will be imported.
import operation.
of operations.
Importing a Specific Page Customization for a User

2. Import metadata by selecting the importMetadata operation available from the
Operations tab.

3. For fromLocation, enter the path of the directory or archive from which the
documents will be imported.
4. For excludeBaseDocs, select true. A Boolean value indicating whether to exclude
base metadata documents from being imported.
To import customizations for a specific page, simply enter the fully qualified base
document name in the Element box.
For example:
/oracle/retail/apps/framework/uishell/skin/page/TestTablesAndTrees.jsff
You can provide the path to multiple documents to be imported, by clicking the
Add. When done, click OK
For example:

Value Description
example, buyer)
import operation.
of operations.
Creating Metadata Labels

2. Create metadata label by selecting the createMetadataLabel operation available
from the Operations tab.
3. For label, enter a valid name of the new metadata label to be created.

operation.
of operations.
Promoting Metadata Labels

2. Create metadata label by selecting the promoteMetadataLabel operation available
3. For label, enter a valid name of the new metadata label to be promoted. Promoting
metadata labels can be used to roll back to an earlier version of the document, as
captured by the label.
operation.
of operations.
Listing Metadata Labels

2. List all metadata labels by selecting the listMetadataLabels operation available
operation.
4. This will list all the available metadata labels previously created. You can use this,
for example, to get the latest metadata label that you want to promote.
5. Click Return to return to the list of operations.
Deleting Metadata Labels

2. Delete metadata label by selecting the deleteMetadataLabel operation available
3. For label, enter a valid name of the metadata label to be deleted.
operation.
of operations.

4
Security in Retail Applications
4
Retail Applications leverage ADF's security framework that is based on the Oracle
[2]
Platform Security Services.
This section discusses the various assumptions around security for Retail
Applications.
Single Sign-on Setup for RAF Applications

RAF provides the following applications as enterprise archive (EAR) files to Retail
Applications. By default, these applications are installed as part of Retail Applications.
■ RetailAppsAdminConsole(RAAC)
■ RetailAppsMobileSecurity
– RetailAppsMobileBasicAuth
– RetailAppsMobileAccessService
■ RetailAppsRESTServices
In SSO environment, follow the SSO setup procedure for these applications similar to
Retail Applications.
Displaying External Application Contents in Non-SSO Environments

Retail Applications allow retailers to display content from external applications. These
contents are typically business intelligence reports from a third party application that
are configured to display within the Retail Application's dashboard.
Some of these contents might be secured requiring users to login before the contents
can be accessed and displayed.
In non-SSO environments, when a user logs out of the Retail Application, they may
not be logged out of any secured content they had configured access to. Therefore, it is
highly recommended that customers only configure access to external content in a
SSO-enabled environments where the application logout manages the logout from any
other secured content that was previously accessed.
Security in Retail Applications 4-1


5
Web Services in Retail Applications
5
This chapter gives an overview about the Allocation ReSTful Web Service
Implementation and API designs used in the Allocation environment. Retailers can
access back-end functionality in Retail applications by calling the applications' ReSTful
Web Services.
Refer to http://www.oracle.com/technetwork/articles/javase/index-137171.html
to learn more about ReST as an architectural style applied to building Web services.
Common Characteristics of Retail Application ReSTful Web Services

This section describes the common characteristics.
Deployment
A Retail Application will package its ReST services as part of the application's
Enterprise Archive (EAR) file. Specifically, those services are packaged as a Web
Archive (WAR) within the EAR.
Installation of the ReST web services is therefore done by default.
Security
Services are secured using J2EE-based security model.
■ Realm-based User Authentication. This verifies users through an underlying
realm. The username and password is passed using Http Basic authentication.
■ Role-based Authorization. This assigns users to roles, which in turn are granted or
restricted access to resources/services. The authorization of ReSTful web services
is static and cannot be reassigned to other rules post installation. The following
role(s) is/are associated with ReSTful Web Services and should be added to the
Enterprise LDAP:
All enterprise roles defined above are mapped in web.xml and weblogic.xml of the
ReST Service webapp.
The communication between the server and client is encrypted using one way SSL. In
non-SSL environments the encoding defaults to BASE-64 so it is highly recommended
that these ReST services are configured to be used in production environments secured
with SSL connections.
Standard Request and Response Headers

Retail Application ReSTful web services have the following standard HTTP headers:
Web Services in Retail Applications 5-1

List of ReSTful Web Services
Accept: application/xml or application/JSON

Accept-Version: 15.0 (service version number)
Accept-Language: en-US,en;q=0.8
Accept-Versioning: False
Note: Specify 'Accept-Versioning: False' in the Service Request to

bypass 'Accept-Version' validation on services.
Depending on the type of the operation or HTTP method, the corresponding response
header is updated in the Http response with the following codes:
■ GET/READ : 200
■ PUT/CREATE : 201 created
■ POST/UPDATE : 204
■ DELETE : 204
Standard Error Response

Example response payload in case of service error is depicted below:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<messagesRDOes>
<messagesRDO>
<message>REST Service Version Mismatch</message>
<messageType>ERROR</messageType>
<status>BAD_REQUEST</status>
</messagesRDO>
</messagesRDOes>
■ message: The error message - translated.

■ messageType: Value of 'ERROR' is returned.
■ status : For a bad request or error, the status is BAD_REQUEST.
■ The http error code for an error response is 400.

This section covers the following:
■ Platform ReSTful Web Services
■ Allocations
Platform ReSTful Web Services

This section lists Web Services provided by the Retail Fusion Platform.
Notification ReST Services

Service endpoints have been enabled for the Notifications Framework. These
endpoints are deployed separately and can be accessed by the following url:
http://server:port/RetailAppsReSTServices/services/private/Notifications/*
The endpoints exposed are detailed below.

Table 5–1 Notification ReST Services

Description URL HTTP Method
Creating Notifications /Notifications/create POST
Updating Notifications /Notifications/update PUT
Deleting Notifications /Notifications/delete/{id} DELETE
Fetch Notifications /Notifications/fetch?appCode={appCode} GET
Get number of unread /Notifications/fetch/unreadCount?appCode={app GET
Notifications Code}
Search Notifications /Notifications/search?appCode={appCode} GET
Filter Notifications - Return list of /Notifications/filter/list POST
Notifications
Filter Notifications - Return /Notifications/filter/group POST
grouped list of Notifications
Filter Notifications - Return a /Notifications/filter/summarize POST
summarized list of Notifications
Count Notifications matching the /Notifications/filter/count POST
filter
Persist the Criteria /Notifications/criteria POST
Fetch the Criteria /Notifications/fetch/criteria?appCode={appCode} GET
Fetch Recipients /Notifications/fetch/recipients/{id} GET
Fetch Notification Context /Notifications/fetch/context/{id} GET
Fetch Notification Time Periods /Notifications/fetch/timeperiods?appCode={appC GET
ode}
Fetch Notification Hierarchy /Notifications/fetch/hierarchylevels?appCode={ap GET
Levels pCode}
Fetch Notification Types /Notifications/fetch/notificationtypes?appCode={a GET
ppCode}
Status update for multiple /Notifications/update/multiple/status PUT
Notifications
Delete multiple Notifications /Notifications/delete/multiple POST
Access Control ReST Service
Table 5–2 Access Control ReST Service

FetchFilteredRoles /AccessRoles POST

Favorites ReST Services
Table 5–3 Favorites ReST Services

Fetch all Favorites /Favorites/fetch GET
Add a Favorite /Favorites/add POST
Delete a Favorite /Favorites/delete DELETE
Update a Favorite /Favorites/update POST
Replace a Favorite /Favorites/replace POST
Allocations
This section covers the following:
■ Approve
■ Load Recent Allocations by User
■ Load by Query
■ Load by Allocation ID
■ Load Item Location Information
■ Lookup Allocation Status
■ Lookup Process Status
■ Reserve
■ Submit
■ Withdraw
Approve
Business Overview
REST endpoint for approving an allocation.
Service Type
Post
ReST URL
/Allocations/approve
Parameter(s)
AllocationRDO - {"id": Value}
Returns
No content response.
Allowed Job Roles

ALLOCATOR, ALLOCATION_MANAGER

Load Recent Allocations by User
Business Overview
REST endpoint for loading recent allocations of logged in user.
Service Type
Get
ReST URL
/Allocations/recent/{records}
Parameter(s)
records - number of records to return
Returns
A collection of AllocationRDO
Allowed Job Roles

ALLOCATOR, ALLOCATION_MANAGER, BUYER
Load by Query
Business Overview
REST endpoint for loading allocations that satisfy the supplied criteria.
Service Type
Get
ReST URL
/Allocations?dept={dept}&class={class}&subclass={subclass}&id={id}&status={status}
&allocStatus={allocStatus}&createdDate={createdDate}&createdBy={createdBy}
Parameter(s)
■ dept - department of the items within an allocation
■ class - class of the items within an allocation
■ subclass - subclass of the items within an allocation
■ ID - comma separated allocation IDs
■ status - the process status of an allocation
■ allocStatus - the status of an allocation
■ createdDate - created date of an allocation in yyyy-MM-dd format
■ createdBy - userId information of the user who created allocation
Returns
Allowed Job Roles


Load by Allocation ID
Business Overview
REST endpoint for loading allocation header based on allocation id.
Service Type
Get
ReST URL
/Allocations/{id}
Parameter(s)
id - allocation id
Returns
Allowed Job Roles

Load Item Location Information
Business Overview
REST endpoint for loading item location information based on supplied information.
Service Type
Get
ReST URL
/Allocations/{id}/itemloc?facetSessionId={facetSessionId}&allocType={allocType}&ite
mId={itemId}&whId={whId}&docType={docType}&docId={docId}&diffDescription={
diffDescription}&diffTypeId={diffTypeId}
Parameter(s)
■ ID - allocation ID
■ facetSessionId - facet session ID associated with the allocation. This ID is
generated from a loaded allocation.
■ allocType - type of allocation. Acceptable values: SA, FA, or FPG.
■ itemId - item ID
■ whId - warehouse ID associated with the item
■ docType - source type where the item is source from. Acceptable Values (PO, ASN,
OH, WHIF, BOL,TSF)
■ docId - source order number
■ diffDescription - diff description retrieved from allocation details service
■ diffTypeId - diff type ID retrieved from allocation details service

Returns
A collection of ItemLocRDO
Allowed Job Roles

Lookup Allocation Status
Business Overview
REST endpoint for looking up allocation statuses.
Service Type
Get
ReST URL
/Allocations/allocStatus
Parameter(s)
None
Returns
A collection of LookUpRDO
Allowed Job Roles

Lookup Process Status
Business Overview
REST endpoint for looking up process statuses.
Service Type
Get
ReST URL
/Allocations/status
Parameter(s)
None
Returns
A collection of LookUpRDO
Allowed Job Roles


Reserve
Business Overview
REST endpoint for reserving an allocation.
Service Type
Post
ReST URL
/Allocations/reserve
Parameter(s)
Returns
Allowed Job Roles

Submit
Business Overview
REST endpoint for submitting an allocation.
Service Type
Post
ReST URL
/Allocations/submit
Parameter(s)
Returns
No content response
Allowed Job Roles

Withdraw
Business Overview
REST endpoint for withdrawing an allocation.
Service Type
Post

ReST URL
/Allocations/withdraw
Parameter(s)
Returns
Allowed Job Roles



6
In-Context Launching Task Flows in Retail
6
Applications
Retail Applications can expose select task flows retailers can directly launch into. This
feature is referred to as in-context launching in a Retail Application.
Retailers can launch these task flows directly through specific URLs.
Retail Applications will provide information about the various task flows retailers can
in-context launch into including the URLs and the required parameters.
Retailers can use these URLs in other web pages as links. For example: the URL to a
task flow that invokes the Create Allocation Flow in a Retail Application can be added
as a link to dashboard report on a BI server.
When the user clicks on a URL to a task flow, the Retail Application will open in a new
browser window or tab depending on the specified target of the URL. The requested
task flow will be shown as a UI tab within the Retail Application.
Limitations of In-Context Launch via URLs

■ The In-Context launch feature will not detect if there is an already opened window
or tab for the Retail Application. So when a user clicks on a link to a Retail
Application's task flow, say, a report on a BI server, a new browser window or tab
will be opened even though the user already has an existing browser window or
tab opened for that same Retail Application.
■ If a BI dashboard is added on the Retail Application, and if that dashboard has a
report that contains links to in-context launchable task flows in the same Retail
Application, a new browser window or tab will still be opened.
List of In-Context Launch Task Flows

Allocation utilizes the following in-context task flows:
■ Quick Create Allocation by Passing Source or Item IDs
■ Load Allocation
■ Quick Create Allocation by Passing Item Id and WH IDs
Quick Create Allocation by Passing Source or Item IDs

The Quick Create Allocation container is a quick way to create an allocation by passing
Source or Item Ids.
HTTP URL
In-Context Launching Task Flows in Retail Applications 6-1

List of In-Context Launch Task Flows
http://<host>:<port>/<app-web -context>/faces/<home view>?navModelItemId=

allocationCreateFromBI1
Table 6–1 Quick Create by Passing Source or Item IDs

Parameter ID Required? Description Sample URL
source Yes Source_type http://...?navModelItemId=
allocationCreateFromBI1?source=PO
sourceIdList Yes sourceIdList http://...?navModelItemId=
allocationCreateFromBI1?source=PO&
sourceIdList=10234;10234
itemIdList Yes Source_type http://...?navModelItemId=
allocationCreateFromBI1?
itemIdList=ASN
Load Allocation
The Load Allocation container allows you to load allocations by passing the Alloc_id.
HTTP URL
Table 6–2 Allocation Create

allocationId Yes allocationId http://...?navModelItemId=
allocationId=10234
Quick Create Allocation by Passing Item Id and WH IDs

The Quick Create Allocation container is a quick way to create an allocation by passing
Item Id and WH Ids.
HTTP URL
Table 6–3 Quick Create by passing Item ID and WH IDs

source Yes source http://...?navModelItemId=
allocationCreateFromBI4? source=WH
itemIdList Yes Items http://...?navModelItemId=
source=WH&itemIdList=103490343
warehouseIdLis Yes source http://...?navModelItemId=
t allocationCreateFromBI4?source==WH
&itemIdList=103490343&
warehouseIdList=20002

7
Customizing Retail Applications
7
This chapter key concepts, guidelines, and supported use cases for customizing a
Retail Application.
Prerequisite Concepts
Retailers must understand the following concepts before performing any of the
supported customization scenarios discussed in this chapter.
■ Understanding the Deployment of Retail Applications
■ Understanding the Retail Application User Interface
Understanding the Deployment of Retail Applications

In order to customize the Retail Application, retailers must understand the
deployment of the Retail Application.
A Retail Application can install one or more application artifacts into a WebLogic
server instance. The diagram below shows a typical installation of a Retail
Application:
Figure 7–1 Retail Application Typical Installation
The Retail Application is deployed as a standalone application and deployed using an

EAR file.
Customizing Retail Applications 7-1

Two shared libraries are typically installed along with the application EAR:
■ The Included Dashboards Shared Library
■ The Custom Shared Library Registry
The Included Dashboards Shared Library contains the Retail Application-built
dashboards. These dashboards can be customized. Further discussion on Retail
Application Included Dashboards can be found in the section, Understanding
Dashboards in Retail Applications.
A Retail Application that allows for customization will have as part of its installation
an intermediary shared library that will serve as a registry to reference the actual
retailer-built shared libraries. This is called the Custom Shared Library Registry.
When retailers need to add their own content into the application, metadata to register
their content into the application's UI including the binaries for the content itself (e.g.
task flows and pages) are expected to be packaged into a Web Archive (WAR) file and
deployed as a shared library in the same managed server as the application itself.
Then, the names of these shared libraries have to be referenced in the Custom Shared
Library Registry.
Figure 7–2 Custom Shared Library Registry
Understanding the Retail Application User Interface

Retail Applications allow retailers to add and display custom content such as new
workflows and dashboards. These custom contents can be accessed from the Retail
Application's user interface (UI).
The Retail Application user interface organizes the contents into visual containers that
fulfill common layout and navigational requirements in a structured, consistent
manner.

Figure 7–3 Retail Application User Interface
The high-level containers or areas in the UI are highlighted below:

■ Global Area
■ Navigation Pane and Sliding Sidebar Menu
■ Local Area
■ Contextual Area
Figure 7–4 User Interface Containers
The Local Area is the main content area of the application. Workflows that allow users
to get tasks done in the application are presented in this area. The workflows are
launched into this area as a result of actions the user take in the navigation pane,
sliding sidebar panel and global area.
The Navigation Pane organizes the different actions a user can take on the application
as iconic menu items. The options or actions available to the users for each menu item
is presented in the Sliding Sidebar panel next to the Navigation Pane. There are five (5)
standard Navigation Pane menus that are available to users:
■ Application Navigator/Switcher – This menu allows users to switch between
■ Favorites – This menu allows users to access their own favorite list of actions or
tasks within the application.

Supported Customization Scenarios
■ Tasks – This menu presents a hierarchy of tasks or actions the user can access in
the application.
■ Reports – This menu presents a hierarchy of links to the application reports and
dashboards.
■ Notification – This menu allows users to access unread and past notifications
around business processes that are happening in the application.
The Global Area of the application contains branding information on the left hand side
and application wide menu options on the right hand side. Application wide menu
options include access to application preferences, login and logout, application help
and application information.
The Contextual Area is a collapsible area on the right of the page, which provides
space to present information that can assist users in completing their tasks. The
Contextual Area is presented per Local Area tab. Each task flow is presented in the
local area can have a contextual area.

When retailers want to add new content such as new pages, business components, or
even Java code into a Retail Application, retailers will need to create a custom shared
library, deploy that into the same managed server as the Retail Application, and
register that library into the Retail Application.
Adding a Custom Shared Library

As discussed in the section, Understanding the Deployment of Retail Applications, a
Retail Application that allows for customization will have as part of its installation an
intermediary shared library that will serve as a registry to reference the actual
retailer-built shared libraries. This is called the Custom Shared Library Registry.
This section contains steps retailers can follow to create a custom shared library that
will contain new custom made content, reference that shared library from the registry,
and deploy it to the server.
Downloading JDeveloper
To create the custom shared library, it is recommended that retailers download and
install JDeveloper version 12.2.1 by following the link below:
http://www.oracle.com/technetwork/developer-tools/jdev/downloads/index.htm
l
Creating the Custom Shared Library Workspace through JDeveloper

This section describes the steps to create and configure the Custom Shared Library
Workspace in JDeveloper, which will house the code for any custom content the
retailer wants to add into the Retail Application. Through JDeveloper, a shared library
web application archive file (.WAR) can be generated which can be deployed in the
same managed server as the Retail Application.
1. Open JDeveloper and choose Developer Role when prompted.

2. Create a new Fusion Web Application JDeveloper workspace.

a. Go to File > New to invoke the New Gallery dialog. Choose Fusion Web
Application (ADF) as the type of application to create and click OK.
b. Provide a meaningful application name, a directory path to the workspace,

and an application (Java) package prefix. Click Finish.

c. JDeveloper will generate a new workspace with two projects: Model and
View-Controller.
3. Add a Manifest file containing the name of the shared library.

a. Right-click on the View-Controller project and choose New from the Context
menu.

b. The New Gallery dialog appears. Choose the option, File (General), in the All
Technologies section of the dialog. Click OK.
c. The Create File dialog opens. For the File Name, specify MANIFEST.MF. For
the Directory, the new file must be added under the src/META-INF
sub-directory under the View-Controller project's directory.

d. Edit the new MANIFEST.MF file and add the following entries:
Manifest-Version: 1.0
Implementation-Vendor: companyName
Implementation-Title: Custom Shared Library for companyName
Implementation-Version: 1.0
Extension-Name: companyname.custom.shared.lib
Specification-Version: 1.0
Created-By: companyName
Modify the contents such that meaningful and unique values are used for
Implementation-Vendor, Implementation-Title, Extension-Name, and Created-By.
Example:
Manifest-Version: 1.0
Implementation-Vendor: Acme Retail
Implementation-Title: Custom Shared Library for Acme Retail
Implementation-Version: 1.0
Extension-Name: acmeretail.custom.shared.lib.procurement
Specification-Version: 1.0
Created-By: AcmeRetail
4. Create a deployment profile for the shared library.

a. Right-click on the View-Controller project and choose New from the Context
menu.

b. The New Gallery dialog appears. Choose the option, WARFile (Deployment
Profiles), in the All Technologies section of the dialog. Click OK.
c. Provide a unique and meaningful name for the Deployment Profile and click
OK.

d. The Edit WAR Deployment Profile Properties dialog is shown.
e. Under the General section, make sure that the Specify Java EE Web Context
Root is selected without any value.
When you navigate away from this section, you will be prompted to confirm
that you really want a blank context root. Click Yes to the confirmation dialog.
f. Under the WAR Options section, enable the Include Manifest File option and
Add the MANIFEST.MF file you created under
…/View-Controller/src/META-INF.
g. Click OK.

Generating and Deploying the Custom Shared Library WAR

This section describes the steps on how to generate and deploy the Custom Shared
Library WAR file:
1. Generate the share library WAR file through JDeveloper.
a. Open the Custom Shared Library workspace.
b. Right-click on the View-Controller project and choose the shared library WAR
deployment profile created previously under the Deploy option.
c. The Deploy dialog opens. Select Deploy to WAR and click Finish.
d. JDeveloper generates the WAR file into the View-Controller project folder
sub-directory, deploy.

2. Deploy the generated WAR file to the same managed server as the Retail
Application as a shared library. Refer to section 6 of the Deploying Applications
to Oracle WebLogic Server documentation (http://docs.oracle.com/cd/E23943_
01/web.1111/e13702/deploy.htm). This task has to be done using the WebLogic
Administration Console or Enterprise Manager Fusion Middleware Control with a
user having WebLogic administrator permissions.
Referencing the Custom Shared Library from the Retail Application

Once the retailer has created and deployed its own custom shared library, the retailer
needs to modify the configuration of the Custom Shared Library Registry to add
references to the retailer's shared library.
oracle.retail.apps.alc..portal.extension
To do this:
1. Log in to the WebLogic Administration Console as a user with administrative
permissions.
2. If the Administration Console was configured with domain configuration locking,
go ahead and click Lock & Edit to ensure that other administrators can be
prevented from making changes during your edit session.

3. Navigate to the Deployments section.
4. Look for the Retail Application deployment and shut it down. Choose Force Stop
Now when appropriate. Wait for the shutdown process to complete.
5. Get the deployment location of the Retail Application's custom shared library
registry. Under the deployments list, click on the link for the library named
oracle.retail.apps.alc.portal.extensions. The Settings page for the library
appears.

The Settings page will show the file location of the registry's WAR file under the
Path entry.
Make a note of this file location.
6. Using the operating system's file manager application, go to the location of the
WAR file. You need read and write permissions to the file system where the WAR
file is located.
7. Make a copy of the WAR file as back-up.
8. Open the original WAR file using an archive file manager and update the
/WEB-INF/weblogic.xml by adding a new <library-ref> entry pointing to your
custom shared library.
<library-ref>
<library-name>companyname.custom.shared.lib</library-name>
</library-ref>
Note: The library-name has to match the Extension-Name you

provided in your custom shared library's MANIFEST.MF file.
Once this change is done, you have now linked your custom shared library to the
Retail application.
9. Return to the WebLogic Administration Console. Navigate to Environments'
Servers section. Under the Control tab, select the managed server where the Retail
Application is deployed to. Shut it down and start it back up again.
Creating New ADF Contents

Custom ADF and Java based components can be coded into the Custom Shared
Library workspace. Typically, retailers can include task flows that add new UI
workflows into the Retail Application UI. These task flows may implement:
■ A new workflow to maintain the Retail Application's data.
■ A dashboard page to highlight key performance indicators and important metrics
based on the Retail Application's data.

This section contains important points that developers must consider when building
new custom ADF-based contents for Retail Applications.
Custom Shared Library Must Be Regenerated

Custom ADF content must be implemented within the custom shared library
workspace. Retailers must create a new custom shared library workspace if none
exists.
The WAR artifact for the custom shared library must be regenerated and redeployed.
See Adding a Custom Shared Library for additional information.
New Components Should Have Security Grants

Since Retail Applications are secured web applications, the addition of new ADF UI
pages and task flows will need to be secured using the application roles and policies
that are recognized by the Retail Application. The provisioning process is done using
the Oracle Enterprise Manager Fusion Middleware Control console.
Applying ADF Best Practices

Developers will be building components in both Model and View-Controller layers
using the tools and standards available for Oracle ADF. New ADF screens will have
their own business components, task flows, pages, and bindings. These components
must comply to published best practices and standards for that technology.
Refer to the Oracle JDeveloper and Oracle ADF Technical Resources web site
(http://www.oracle.com/technetwork/developer-tools/jdev/learnmore/index.ht
ml) . Of particular interests are coding guidelines published under the ADF
Architecture Square section of the site
(http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adfarchit
ect-1639592.html).
Task Flow and Page Configuration Must Be Supported

Task flows must be built as bounded task flows using JSF page fragments.
The task flow must have an isolated data control scope. This is configured in
JDeveloper's task flow designer by going to the Behavior tab and setting data control
share option as "Isolated".
The Same Data Source Must Be Used

New application modules must be configured to use Data Sources and not JDBC URLs
when accessing the database layer. This can be configured in JDeveloper's application
module designer.

The data source name must be the same as the Retail Application's primary data
source name.
jdbc/AllocationApplicationDBDS
Adding or Modifying an Item in the Reports Menu

To add new contents in the Retail Application's Reports Menu, the retailer must
override the reports menu model.
All items seen by the user in the Reports Menu are registered in an XML file called the
Reports Menu Model.
This file is kept in the application's EAR file but can be extracted, copied and modified
so retailers can add references to their own dashboards or reports.
To add or modify an item in the Reports Menu, follow the steps below:
1. Add a custom shared library. See Adding a Custom Shared Library for additional
information.
2. Using JDeveloper, open the Custom Shared Library workspace in Developer Role.
3. Add new custom reports as required.
4. Regenerate the shared library WAR file from the workspace and redeploy the
shared library. Shutdown and restart of the Retail Application and its shared
library registry is required.
5. Changes Required in Shared Library Registry for Custom Reports Menu Model:
a. Obtain the application's Reports menu model XML file.
Reports Menu Model XML –
EarAllocCore.ear\AlcPublicUIViewController.war\WEB-INF\classes\oracle\
retail\apps\framework\uishell\config\custom\HomeReportsMenuModel.x
ml
b. Please refer the Section Reference the Custom Shared Library from the Retail
Application., to register custom reports menu model shared library within the
Retail Application.

c. Open the original WAR file using an archive file manager and copy the above
Reports menu model xml file in View-Controller project src directory,
preferably under a subdirectory called custom.
d. Add a new or modify existing file called
PageTemplateOverrideModel.properties under the View-Controller/src
directory.
Modify this file and add the following entry:
Home.reportsMenuModelXml=<path to sidebar model xml within
view-controller/src>
Example:
Home.reportsMenuModelXml=/custom/HomeReportsMenuModel.xml
e. Modify the copy of the model. Add new items , which are created in the
shared library project. Refer to the section, Reports Menu Model XML Items.
6. Test the Retail Application.
Reports Menu Model XML Items

The Reports menu model is composed of Item elements. An item renders as either a
launchable link or a submenu in the Reports menu of the Retail Application. Below is
an example of what a Reports Menu Model XML might look like:
<NavigationDefinition … >
<Items>
<Item id="myFolder" title="My Folder" type="folder">
<Items>
<Item id="myContent" type="taskflow"

title="My Content">
<url>
/WEB-INF/mycompany/CustomDashboardTaskFlow.xml#CustomDashboardTaskFlow
</url>
<Parameters>
<Parameter id="productName">"Acme"</Parameter>
</Parameters>
</Item>
</Items>
</Item>
</Items>
</NavigationDefinition>
Item Attributes
Attribute Description
visible Indicates if the item should be rendered (visible) or not.
It can be an EL Expression that evaluates to true or false. Or it
can be a plain string value equal to "true" or "false". Defaults to
"true".
type Indicates the type of the item. The main values are
"folder","taskflow","link". The type "folder" indicates that the
item contains additional sub-navigation items. The type
"taskflow" indicates it is a task flow, and the type "link" is used
for URLs.

title The attribute title is used to provide the title of the sidebar item.
This attribute is a required attribute.
targetTitle The attribute targetTitle is used to provide the title of the tab in
the content area. This attribute is an optional attribute. If not
provided, the value of the title attribute will be used as the title
of the tab in the content area.
accessKey The attribute accessKey is used to specify the keyboard
keystroke or a group of keystrokes that are used to access the
navigation item using the keyboard.
shortDesc The attribute shortDesc is used to provide the description of the
navigation item which will be displayed when the user hovers
over a menu item.
showCloseIcon Mainly used when the content is being rendered in a popup,
and indicates if the 'x' icon should show or not on the top right
corner of the popup to facilitate manual closing of the popup.
Takes the values "true" or "false". Defaults to "false".
defaultContent Indicates whether the corresponding items from the model
show up by default in tabs in the content area when the page
template loads. Takes values "true" or "false", or may even take
an EL Expression evaluating to "true" or "false".
reuseInstance The attribute reuseInstance is used to specify whether the
navigation items with the same title and url will use the same
tab or not. When this attribute is set to false, the request to open
the content for that navigation item will always use a new tab.
When the attribute is true, the navigation items with the same
title and url will share the same tab in the content area. It
defaults to true.
keysList Takes name value pairs separated by a semicolon. The attribute
keysList provides a way to differentiate two navigation items
with the same title and url. If keysList is not provided, then the
two navigation items with the same title and url will always use
the same tab. When the keysList is provided, it provides
uniqueness to the navigation items with the same title and url
enabling them to use different tabs. Example
keysList="key1=value1;key2=value2"
urlRendererHeight, Example values are shown below. These used in the case of a
popup and indicate the height and width of the popup.
urlRendererHeight, Example values are shown below. These used in the case of a
popup and indicate the height and width of the popup.
urlRendererWidth
urlRendererHeight="200px" urlRendererWidth="200px"
reloadTab When this attribute is set to true, an already opened tab will be
reloaded with the new input parameters for the taskflow.
When it is set to false,
a previously opened tab will only be re-focused, but not
reloaded with new input parameters for the taskflow.
The reload tab functionality has some limitations. Please see
section 'Error! Reference source not found.

refreshOnDisclosure When the navigation item has refreshOnDisclosure attribute set
to true then the tab displaying that item in the Content Area will
be refreshed every time it's disclosed. The attribute can take
either of the two values true or false. Default is false. The
attribute is useful in the scenarios where we want to display to
the user the latest information from the database every time
he/she comes back to the tab. The attribute should be used with
caution because if the data in that tab is not committed before
leaving the tab then the uncommitted data will be lost upon
coming back to the tab.
dynamicTabFocus When a navigation item is invoked, the tab displaying that item
will have its text focused. To override this behavior, set
dynamicTabFocus to "false". This attribute defaults to "true".
popupId Applicable only when target="_popup". Must be a number
between 1 and 15.
This attribute allows consuming applications to target a specific
popup within the UI Shell. The framework provides 15 popups
that consuming applications can take advantage of.
In case this attribute has not been specified, a default popup
will be used by the framework. This default popup will not
store its dimensions in MDS.
popupContentHeight Applicable only when target="_popup".
This attribute is used to provide the height in pixels of the
resulting popup dialog window.
popupContentWidth Applicable only when target="_popup".
This attribute is used to provide the width in pixels for the
resulting popup dialog window.
popupStretchChildren Applicable only when target="_popup".
This attribute is used to indicate the stretching behavior for the

contents of the resulting popup window.
The contents are referred to as child components.
Valid values are:

■ none - does not attempt to stretch any children (the default
value and value you need to use if you have more than a
single child; also the value you need to use if the child does
not support being stretched).
■ first - stretches the first child (not to be used if you have
multiple children as such usage will produce unreliable
results; also not to be used if the child does not support
being stretched).
popupResize Applicable only when target="_popup".
This attribute is used to indicate the resulting popup window's
resizing behavior. Valid values are:
■ on - user can resize the dialog with their mouse by
dragging any of the dialog edges.
■ off - the dialog automatically sizes its contents if
popupStretchChildren is set to "none"

popupHelpTopicId Applicable only when target="_popup".
This attribute is used to look up a topic in a helpProvider for the
resulting popup window.
popupShortDesc Applicable only when target="_popup".
This attribute is used to provide short description of the
resulting popup window.
contentListener Specifies the fully qualified name of the class implementing the
ContentListener interface.
This allows applications to have the ability to inject any session
or request values before opening tabs.
tabShortDesc Specifies the text to be shown when the user hovers over the
application tab. Using this attribute application team can keep
the title short and the tabShortDesc as fully qualified tab name
which can be shown as the tooltip of the tab. This attribute will
be displayed as tab title in screen reader mode.
Item Sub-elements
Sub-element Description
url The location of the item being launched.
If the type is "taskflow" - then the URL element must contain the
path to the task flow XML.
If the type is "link" - then the URL of the external system must
be indicated in this subelement. The entire URL must be
marked as character data (e.g. enclosed in CDATA)
Parameter The <Parameters> sub-element within <Item> should list all the
parameters to the dashboard page if there are any. Each
parameter is represented as a <Parameter> element inside
<Parameters>.
The <Parameter> id should be the actual parameter reference
name recognized by the dashboard URL.
The value of each <Parameter> is a string value. This is the
only supported data type.
Securing Access to Items

To restrict access to report items to specific security roles, set the visible property on
the <Item> element for the dashboard URL to an Expression Language (EL) expression
that calls ADF's securityContext API's isUserInRole method. Example:
<Item id="myDashboard1"
type="link"
title="Profitability Dashboard"
visible="#{securityContext.isUserInRole['BUYER_JOB']}" >
The parameter to the securiytContext.isUserInRole method is a logical security role
that is configured for the Retail Application. The API returns true if the user is
included in the specified security role. If the user is not authenticated or is not found
in the role, the API returns false.
Adding or Modifying an Item in the Tasks Menu

To add new contents in the Retail Application's Tasks Menu, the retailer must override
the tasks menu model.

All items seen by the user in the Tasks Menu are registered in an XML file called the
Tasks Menu Model.
This file is kept in the application's EAR file but can be extracted, copied and modified
so retailers can add references to their own workflows.
To add or modify an item in the Tasks Menu, follow the steps below:
1. Add a custom shared library. Refer to the section, Adding a Custom Shared
Library for details.
3. Add all the custom task menu items as required.
4. Regenerate the shared library registry WAR file from the workspace and redeploy
the shared library. Shutdown and restart of the Retail Application and its shared
5. Changes Required in Shared Library Registry for Custom Task Menu Model
a. Obtain the application's Tasks menu model XML file.
Tasks Menu Model XML –
/oracle/retail/apps/framework/uishell/config/custom/HomeTaskMenuMo
del.xml
b. Please refer the section Reference the Custom Shared Library from the Retail
Application, to register custom task menu model shared library with in the
c. Open the original WAR File using an archive file manager and copy the above
TaskMenuModel xml file in the View-Controller project src directory,
d. Add a new file called PageTemplateOverrideModel.properties under the
View-Controller/src directory. Modify this file and add the following entry:
Home.taskMenuModelXml=<path to sidebar model xml within
view-controller/src>
Example:
Home.taskMenuModelXml=/custom/HomeTaskMenuModel.xml
e. Modify the copy of the model. Add new itemsdefined in the custom shared
library above. The format of the tasks menu model is similar to the format of
the reports menu model. Refer to the section, Reports Menu Model XML
Items.
Dashboard Customization Scenarios
Understanding Dashboards in Retail Applications

A dashboard is a page within a Retail Application that displays the status of metrics
and key performance indicators relevant to the Retail Application. They are
typically tailored for specific roles and they allow users to easily monitor the status of
the current data within the application.
Users can access dashboards from the application's Reports menu.

The example below shows the dashboard page as rendered in the local area of a Retail
Application's UI.
Anatomy of a Dashboard
Depicted below is an example of a dashboard that might appear in a Retail
Application:
Figure 7–5
1 Dashboard Page A page rendering a dashboard. A

dashboard is composed of 1 or more
reports. The dashboard page is launched
as a tab within the Retail Application

2 Prompt Region The prompt region contains a set of

editable input components that allow users
to modify the parameters of the various
reports in the dashboard. This allows users
to see different sets of data for the same set
of reports. This is optional on a dashboard
page. There can be multiple prompt
regions in a dashboard affecting different
sets of reports on a dashboard.
3, 4, 5 Report Regions A report region shows a graphical view of
the application's business data.
Supported Implementation of Dashboards

Retail Applications support the following implementation of dashboards:
■ Dashboards built using Oracle ADF.
■ Dashboards built in external BI reporting tools and accessible via a web browser
URL.
■ Dashboards built using Oracle ADF is the recommended implementation of
dashboards as they have seamless integration with the rest of the Retail
Application.
■ Dashboards built in external BI reporting tools are supported as long as the
dashboards can be accessed in a web browser via a URL. Oracle Retail
recommends using Oracle Business Intelligence Enterprise Edition (OBIEE) for
URL based dashboards.
■ Dashboards developed externally doesn't support Contextual links to Allocation
Application, that means report can not access the App using contextual links.
Retail Application Included Dashboards

As mentioned in the section, Understanding the Deployment of Retail Applications, a
Retail Application is installed with a shared library containing included dashboards
that are rendered by default within the application.
These dashboards have the following characteristics:
■ The dashboards are implemented in Oracle ADF for seamless integration with the
rest of the application workflows.
■ The dashboards are implemented using a common framework called ADF
Dashboard Prompts to allow for a standard way of customizing them.
Retailers can customize included dashboards. Please refer to the section, Dashboard
Customization Scenarios for details on the types of customization retailers can perform
on included dashboards.
Adding a New ADF-based Dashboard in the Reports Menu

This section describes the steps for adding ADF based dashboard reports into the
Retail Application's UI Sidebar. ADF-based reports can be integrated into the Retail
Application by adding the dashboard report's task flow URL in the application's
reports menu model XML file:
1. Add a new custom shared library. Refer to the section, Adding a Custom Shared
Library.
2. Implement the dashboard page components in the custom shared library
workspace. Dashboard page components are built as Oracle ADF bounded task

flows. Refer to the section, Creating New ADF Contents, for important
considerations when building custom ADF content.
3. Note the task flow URL and the parameters of the dashboard task flow.
4. Register the task flow URL and parameters into the application's Reports Menu
Model. Refer to section, Adding or Modifying an Item in the Reports Menu.
5. Re-generate the Custom Shared Library WAR file from the Custom Shared Library
workspace. Shutdown the Retail Application and its Custom Shared Library
Registry, redeploy the Custom Shared Library WAR file, and restart the Retail
Application components.
6. Grant security permissions to dashboard page components. Refer to the section,
Creating New ADF Contents.
7. Test the Retail Application. Log-in and verify the newly added content.
Adding a New External Dashboard into the Reports Menu

This section describes the steps for adding external dashboard reports into the Retail
Application's UI Sidebar. The reports such as OBIEE, BI Publisher or Microstrategy can
be integrated into the Retail Application by adding the web URL of the dashboard
report in the application's reports menu model XML file:
1. Create the dashboard report in the reporting server instance.
2. Obtain the URL to the dashboard report along with any parameters needed to
render it.
3. Add a New Custom Shared Library. Refer to the section, Adding a Custom Shared
Library.
4. Open the Custom Shared Library workspace in JDeveloper.
5. Add a new item in the reports menu for the URL and parameters of the dashboard
report. Refer to the section, Adding or Modifying an Item in the Reports Menu.
7. Test the Retail Application. Log-in and verify that a link to the BI dashboard
appears in the UI's sidebar task tree under a folder "My Custom Dashboards".
Retail Application Included Dashboard Customization Scenarios

This section contains supported customization use cases for out-of-the-box dashboards
included in the Retail Application installation.
Understanding Design Pattern of Included Dashboards

As mentioned in the section, Anatomy of a Dashboard, dashboards are composed of
prompt regions and report regions.
The representation of those parts at runtime are depicted in the diagram below:

The dashboard page, prompts and reports are implemented as ADF bounded task
Flows and page fragments. The prompts and regions are configured in an XML file
called a Dashboard Prompt Configuration XML. The dashboard prompt XML arranges
visually the prompts and regions on the dashboard page.
The dashboard task flow is launchable from the Retail Application User Interface's
Reports Menu. In order to make the report launchable, the dashboard task flow is
registered in the application's reports menu model XML.
A set of ADF business components enable data from the Retail Application schema to
be rendered in the report regions.
The figure below shows a rendering of a dashboard (called Alloc Dashboard) in a
Retail Application:
The different parts of this example dashboard are described below:

1 Dashboard Page For this example - this called the

Allocations Dashboard or Alloc
Dashboard. It contains 1 prompt and 3
reports.
It is implemented as an ADF bounded task
flow called AllocDashboardFlow.
2 Prompt Region This is the prompt region that users
modify to change the view of the various
reports in this dashboard.
flow called DashboardFilterFlow.
3 Order Status Report A report region showing a row of
information tiles and a detail table.
flow called OrderStatusFlow.
4 Top Seller Report A report region showing the top selling
item.
flow called TopSellerFlow
5 Bottom Seller Report A report region showing the bottom selling
item.
flow called BottomSellerFlow
The dashboard is launched from the application's reports menu. The reports menu
model XML file (as shown below) contains an item called allocDashboard registering
the task flow, AllocDashboardFlow, into the reports menu. Note that the dashboard
task flow includes a parameter called dashboardConfigXML which references the
location of the Dashboard Prompt Configuration XML file.
<NavigationDefinition id="Folder_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:www.oracle.com:oracle.retail.apps.framework.navigation"
xsi:schemaLocation="urn:www.oracle.com:oracle.retail.apps.framework.navigation
classpath:oracle/retail/apps/framework/uishell/navigation/model/schema/NavigationM
odel.xsd">
<Items>
<Item id="allocDashboard" title="Alloc Dashboard"
shortDesc="Alloc Dashboard"
type="taskflow">
<url>/WEB-INF/AllocDashboardFlow.xml#AllocDashboardFlow</url>
<Parameters>
<Parameter
id="dashboardConfigXML">"/oracle/AllocDashboardPrompt.xml"</Parameter>
<Parameters>
</Item>
</Items>
The Dashboard Prompt Configuration XML file for this example is called the
AllocDashboardPrompt.xml and it contains the following entries:
<?xml version="1.0" encoding="UTF-8" ?>
<Dashboard layout="column"
xmlns="urn:www.oracle.com:oracle.retail.apps.framework.dashboard"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:www.oracle.com:oracle.retail.apps.framework.dashboard
classpath:oracle/retail/apps/framework/dashboard/model/schema/dashboardSchema.xsd"
>
<Vectors>
<Vector>
<Items>
<Item id="filter" type="prompt">
<url>/WEB-INF/DashboardFilterFlow.xml#DashboardFilterFlow</url>
</Item>
<Item id="orderStatus" type="report">
<url>/WEB-INF/oracle/retail/apps/framework/dvtcontextawarereport/publicui/flow/DVT
ContextAwareReportFlow.xml#DVTContextAwareReportFlow</url>
<Parameters>
<Parameter
id="taskflowURL">/WEB-INF/OrderStatusFlow.xml#OrderStatusFlow</Parameter>
<Parameter id="parameterName1">departmentIds</Parameter>
<Parameter id="payloadKeyName1">DepartmentId</Parameter>
<Parameter id="parameterName2">classIds</Parameter>
<Parameter id="payloadKeyName2">ClassId</Parameter>
<Parameter id="parameterName3">subclassIds</Parameter>
<Parameter id="payloadKeyName3">SubclassId</Parameter>
</Parameters>
</Item>
</Items>
</Vector>
<Vector width="300px">
<Items>
<Item id="topSeller" type="report">
<Parameters>
<Parameter
id="taskflowURL">/WEB-INF/oracle/retail/apps/flow/TopSellerFlow.xml#TopSellerFlow<
/Parameter>
</Parameters>
</Item>
<Item id="bottomSeller" type="report">
<Parameters>
<Parameter
id="taskflowURL">/WEB-INF/oracle/retail/apps/flow/BottomSellerFlow.xml#BottomSelle
rFlow</Parameter>

</Parameters>
</Item>
</Items>
</Vector>
</Vectors>
</Dashboard>
The file registers the prompts and regions into a hierarchy of vectors and items. The
structure of the dashboard prompt configuration XML file is explained in the
following section.
The Dashboard Prompt Configuration XML File

The root element of the model is the "Dashboard" element. Other than schema and
namespace information, the "Dashboard" element has a "layout" attribute that must be
provided, and must contain a value of either "row" or "column". This attribute
arranges the regions of the dashboard in rows or columns.
Inside the "Dashboard" element is a "Vectors" element, which contains a list of "Vector"
elements. If the dashboard layout="row", then each "Vector" corresponds to a single
row in the dashboard. Conversely, if layout="column", then each "Vector" corresponds
to a column. To add a new row or column, simply add another "Vector" element inside
the "Vectors" element.
Up to 12 rows and 6 columns can be displayed in a dashboard, not including separate
header and footer regions. Any items beyond 12 rows or 6 columns will not appear on
the dashboard.
Rows in the dashboard display from top to bottom. If layout="row", the first "Vector"
will appear toward the top of the page. Columns appear from left to right, so if
layout="column", the first "Vector" will appear toward the left of the page.
Each "Vector" element contains an "Items" element, which contains a list of "Item"
elements. The xml structure for "Item" elements is very similar to the tasks or reports
sidebar menu models.
The following attributes are supported on dashboard items:
Name Description Required?

id A unique id for this region Yes
type The type of content contained in this region. Yes
Valid values: prompt, report
width The width of this region. See below for more details. No
height The height of a region. See below for more details. No
url The task flow url to open in this region Yes
Parameters Parameters to be sent to the URL No
In addition to the items arranged in rows or columns, you can add a header and footer
region to the dashboard. Both horizontally span the full width of the dashboard, with
the header appearing at the top and the footer appearing at the bottom. These can be
added in the model by specifying a "HeaderItem" or "FooterItem" child of the root
"Dashboard" element. These regions support all the same properties as other items in
the dashboard.
Vectors and items expose width and height attributes to enable applications to resize
elements to best fit on the dashboard. Certain rules and best practices apply when
using these attributes.

First, if the dashboard is in row layout, then all items in a row must have the same
height. The height attribute from the vector is used to specify the height of every item
in that row. Since rows are assumed to span the full width, the vector width is ignored
in this layout.
In the same way, when the dashboard is arranged in column layout, all items in a
column must have the same width. The vector width is used to specify the width of
every item in that column. Columns should expand vertically to accommodate all
content, allowing a scrollbar if necessary. Therefore, vector height is ignored in this
layout.
In addition to the width and height attributes, a vector also provides a
dimensionsFrom attribute. The valid values of the dimensionsFrom attribute can be
auto, child or parent. The dimensionsFrom attribute is used to specify whether the
Items in the vector inherit their dimensions from the parent decorative box or not.
When the dimensionsFrom attribute is parent, the Items in the vector will be stretched
to fill any available space in the vector. When the dimensionsFrom attribute is child,
the Items in the vector won't stretch but will display scroll bars if they cannot be
accommodated in the available space in the decorative box. The default value of the
dimensionsFrom attribute is 'auto' which gives preference to the child dimensions.
The following table indicates which attributes are used, based on which dashboard
layout has been selected.
Row layout Column layout

Vector width ignored valid
Vector height valid ignored
Item height ignored valid
Item width valid ignored
In column layout, either every vector width should be provided, or every width
should be omitted. If all widths are omitted, columns default to divide the total width
evenly. When the widths are omitted, the dimensionsFrom attribute of the vector can
be set to parent if stretching of the Items is desired. If widths are provided, they should
be specified as a percentage, and the sum of all widths should equal 100%.
In row layout, heights may be specified or omitted as desired. If a row's height is
omitted, it will default to get the dimension from the content inside the regions. When
the row's height is omitted, the dimensionsFrom attribute of the vector can be set to
parent if stretching of the Items is desired. Heights should be specified using an exact
unit such as px or em. Percentages should not be used.
If these rules and best practices are ignored, results may be inconsistent or undesirable.
Items may not size as intended, and horizontal scrollbars or nested vertical scrollbars
may appear.
In addition to resizing entire rows or columns, individual items inside the row or
column can also be resized. As mentioned above, items in a row should all have the
same height, so in row layout, item height is ignored and only item width is valid.
And items in a column should have the same width, so item width is ignored and only
item height is valid. See the table above for details.
The same rules and best practices that apply to vector height and width also apply to
setting item height and width.

Refreshing Reports on Prompt Changes

When the user changes a value on the dashboard prompt, that value translates as a
parameter change on the different reports on the dashboard.
This is accomplished through a feature in ADF called Contextual Events. To put
simply, contextual events are signals that a page in a task flow can generate for which
pages in other task flows can listen and react to. For the included dashboards,
prompt regions generate a contextual event whenever the user changes a prompt field
value. When a report "hears" an event, it will process the contextual event
information (called a payload) to extract the changed prompt value, use that value as
a parameter to the report query and refresh the report region.
In the example depicted in the previous section, the dashboard prompt configuration
XML file shows all three reports registered under a wrapper task flow called the
DVTContextAwareReportFlow.
<Item id="bottomSeller" type="report">
<Parameters>
<Parameter
id="taskflowURL">/WEB-INF/oracle/retail/apps/flow/BottomSellerFlow.xml#BottomSelle
rFlow</Parameter>
</Parameters>
</Item>
The DVTContextAwareReportFlow wrapper task flow enables a report to listen to

contextual events generated by prompt regions.
Note the pairs of parameterNameN and payloadKeyNameN registered in the
<Parameters> section for the report task flow BottomSellerFlow. A pair of parameter
name and payload key name tells the framework what prompt value is mapped to a
specific report parameter. From the example above, parameterName1 is specified as
"departmentIds" and payloadKeyName1 as "departmentIds". This means the
following:
■ There is a task flow parameter for the BottomSellerFlow called "departmentIds"
■ When the user changes the value of the department ID in the prompt region, the
system will generate a contextual event with the new department value stored as
reference "DepartmentId".
■ The report is context aware (as indicated by the wrapper task flow -
DVTContextAwareReportFlow). When the report detects the contextual event,
the framework will get the new department ID value from the payload by using
the key "DepartmentId", use it to update the BottomSellerFlow task flow's
"departmentId" parameter, and refresh the report region.
For more details on the DVTContextAwareReportFlow, refer to the section Adding a
DVT Taskflow-based Contextual Report.

List of Retail Application Included Dashboards

This section contains a listing of all dashboard reports included in the Retail
Application.
■ Allocator Dashboard
Allocator Dashboard
The Allocator dashboard is designed to show the user a set of reports with important
data points such as incoming purchase orders, stock figures compared against the total
sales values, top and bottom selling items, etc. for a set of selected merchandise
hierarchies. At the top of the dashboard are prompts that need to be selected and are
used to filter the data in the dashboard. At a minimum, a department, one or more
classes, and one or more subclass that belong to this department must be selected.
The dashboard contains the following reports -
Purchase Order Arrivals
This report lists the details of the incoming orders that are due to be delivered in the
next 4 weeks, based on the Not After Date (NAD) of the order. The user is given a
visual representation of the orders in the form of orange circles within a tile
representing each of the 4 weeks; with the current one selected by default. Fully
allocated PO count is shown in orange, partially allocated PO count in green, whereas
fully allocated PO count is shown in blue within the circle that represents the total PO
count for the week. These values are displayed to the user on hovering over the
respective sections of the figure. Selection of the tile representing a week will show the
details of the orders to be delivered in that week in a tabular format.
The user can perform the following actions from the dashboard:
■ Allocate PO - This action is shown as a gear icon in the Action section of the report
and will indicate that the PO has either not been allocated or has not been fully
allocated. Clicking on the icon will take the user to the Allocate PO screen to select
items from the purchase order in which to create the allocation.

■ Reallocate PO - This action is shown as a curved arrow in the Action section of the
report and will indicate that the PO has an allocation associated with it. Clicking
on this icon will take the user to the allocation to make updates.
Stock to Sales
This report plots the historical trend of the stock on hand at the beginning of the given
week and the corresponding sales achieved by the end of the same week for the past
six weeks. The stock and sales is aggregated across all items belonging to the
department, classes, and subclasses selected in the prompts and the stores that are
sourced from the selected virtual warehouse, if selected.
Sales - Top
This report displays yesterday's top selling item based on the merchandise hierarchy
combination selected in the prompts. It is intended to provide visibility to the allocator
to prioritize allocations for the fast selling product in order to get the right product in
time on the sales floor.

Sales - Bottom
This report displays yesterday's lowest selling item based on the merchandise
hierarchy combination selected in the prompts. It is intended to help the allocator
make inventory decisions, based on slow sales.
Adding or Replacing A Report In An Included Dashboard

This section discusses the steps needed to add or replace a report on an included
dashboard.
Library. An existing custom shared library can be reused.
2. Identify the dashboard to be modified. Refer to the section, List of Retail
Application Included Dashboards.
3. If needed, open the custom shared library workspace in JDeveloper and build
your own custom report as an ADF bounded task flow. Refer to the section,
Creating New ADF Contents.
If the report has to refresh when a prompt on the dashboard is changed by the
user, make sure that task flow parameters are present for the prompt values your
report will need to react to. Refer to the section, List of Retail Application Included

Dashboards, for a list of prompt payload values that can be generated for the
dashboard.
4. Note the new report's task flow URL and parameters.
5. Obtain a copy of the dashboard prompt configuration XML file for the dashboard
to be modified. Refer to the section, List of Retail Application Included
Dashboards.
6. Modify the copy of the dashboard prompt configuration XML file to add an item
or replace an existing item for the new report. Refer to the section, The Dashboard
Prompt Configuration XML File for details on properly creating a new item entry
in the configuration file.
If the report has to refresh when a prompt on the dashboard is changed by the
user, make sure that report task flow is wrapped in a DVTContextAwareTaskFlow
for its item entry in the dashboard prompt configuration XML file. Use the
example in the section, Understanding Design Pattern of Included Dashboards, as
reference. Refer to the section, Adding a DVT Taskflow-based Contextual Report
for usage of the DVTContextAwareTaskFlow framework.
7. Modify the included dashboard's entry in the application's Reports Menu to
reference the location of your copy of the dashboard prompt configuration XML
file. Refer to the section, Adding or Modifying an Item in the Reports Menu.
Removing a Report From An Included Dashboard

This section discusses the steps needed to remove a report from an included
dashboard.
Dashboards.
4. Modify the copy of the dashboard prompt configuration XML file and remove the
report. You may need to readjust the position of the other reports. Refer to the
section, The The Dashboard Prompt Configuration XML File for details on the
configuration XML attributes that control the rendering of the dashboard.

Change the Layout Of An Included Dashboard

This section discusses the steps needed to change the layout of the reports in included
dashboards.
Dashboards.
4. Modify the copy of the dashboard prompt configuration XML file and rearrange
the position of the item entries. Refer to the section, The Dashboard Prompt
Configuration XML File for details on the attributes to control the layout of
dashboard.
Adding Contextual Reports

Contextual Reports are reports that appear in a task flow's contextual area section. As
discussed in the section, Understanding the Retail Application User Interface, the
Contextual Area is a collapsible section to the right of the local area that provides a
space to present information that can assist users in completing their tasks.
Since information presented in a contextual area is presented depending on the task or
workflow the user is on, contextual areas are associated to task flows and there can be
at most one contextual area per task flow.
Within a contextual area - multiple contextual reports can be configured.
Each contextual report can change its contents depending on the action being
performed in the user's current workflow.
For example, in the screenshot below, as the user selects the line of business from the
table, the line chart will show the annual trade for the selected line of business.

Each task flow publishes contextual business events on key activities happening in the
screen. Contextual reports can listen to those events and change its content depending
on the payload information associated with the event.
Contextual reports can either be ADF based DVT reports or can be maintained in a
separate BI reporting tool. The ADF based DVT reports are ADF taskflows, which are
built using the ADF Data Visualization components. The reports maintained in an
external reporting tool are URLs accessible in a web browser via a URL. Oracle Retail
recommends using Oracle Business Intelligence Enterprise Edition (Oracle BI EE) for
an external reporting tool.
The contextual reports are added into a Retail Application by adding and configuring
the task flow's contextual area model XML file into the Custom Shared Library.
Retail Applications may provide retailers with a list of possible contextual business
events each flow generates. Retailers can configure their contextual reports to react to
these events. Each event will also include information about the event's payload
information (example: the item ID of the item being selected in an Allocation
Maintenance screen).
List of Contextual Business Events and Payloads
Contextual Contextual Area

Event Name Task Flow Area Name Model XML Location Generated when… Payload Values
AllocMaintItem AllocMaintFlo AllocationMain WarAllocDashboardS The user select the ■ Item
SelectedEvent w tenancePageDef haredLibrary.war\W review section to fire
■ allocId
.xml EB-INF\classes\oracl this even
e\retail\apps\frame ■ diff1
work\uishell\config
■ diff3
\custom\Contextual
AreaModel.xml ■ diff3
■ diff4
■ sessionid

Contextual Contextual Area

Event Name Task Flow Area Name Model XML Location Generated when… Payload Values
itemSourceLoc AllocResultsFlo AllocResultsPa WarAllocDashboardS The user select the ■ Item
EventBinding w geDef haredLibrary.war\W review section to fire
■ locationid
EB-INF\classes\oracl this even
work\uishell\config
■ diff3
\custom\
ContextualAreaMode ■ diff3
l.xml
■ diff4
■ loctype
■ sessionId
itemforcastEve AllocResultsFlo AllocResultsPa WarAllocDashboardS The user select the ■ Item
ntBinding w geDef haredLibrary.war\W review section to fire
■ locationid
EB-INF\classes\oracl this even
work\uishell\config
■ diff3
\custom\
ContextualAreaMode ■ diff3
l.xml
■ diff4
■ loctype
■ sessionId
Preparing the Custom Shared Library for Adding Contextual Reports

This section describes how to prepare the Custom Shared Library so retailers will be
able to add contextual reports in Retail Application task flows.
1. Perform the steps described in the section Add a Custom Shared Library to create
a Custom Shared Library workspace, generate a shared library WAR out of it,
deploying the WAR, and associating the library to the Retail Application.
3. Add new contents as required.
4. Regenerate the shared library WAR file from the workspace and redeploy the
shared library. Shutdown and restart of the Retail Application and its shared
5. Changes required in Shared Libarary Registry for Custom Contextual Reports
a. Obtain a copy of the task flow contextual area model XML files where
contextual reports will be added. Refer to section, List of Contextual Business
Events and Payloads.
Example: If the contextual area model XML for the task flow AllocMaintFlow
is called AllocMaintFlowContextualAreaModel.xml - then that file's path must
be View -Controller/src/custom/AllocMaintFlowContextualAreModel.xml.
b. Please refer the section Referencing the Custom Shared Library from the Retail
Application to register custom contextual reports shared library with in the
c. Open the original WAR file using an archive file manager and copy the
contextual area model XML file in the View-Controller project src directory,

d. Add a new or open the existing file called

PageTemplateOverrideModel.properties under the View-Controller/src
directory. Modify this file and add the following entry:
<ContextualAreaName>.contextualAreaModel=<path to the contextual area model
for the flow>
Example:
AllocMaintFlow.sidebarModel=/custom/AllocMaintFlowContextualAreaModel.xml
6. Test the Retail Application. Navigate to the flow and make sure the flow is
functional.
Adding a URL based Contextual Report

Adding a contextual report to a task flow entails the modification of the task flow's
Contextual Area Model XML file. Multiple reports can be added to the model. Each
report is rendered in a collapsible panel box.
Before adding a URL based contextual report, the retailer must have:
■ Built, prepared, deployed, and tested the Custom Shared Library as described in
the section, section Preparing the Custom Shared Library for Adding Contextual
Reports.
■ Obtained information about the Retail Application's list of contextual business
events that can be broadcast from various workflows.
■ Created one or more contextual BI reports in the BI reporting tool (e.g. Oracle BI
EE).
– The web URL for each report must be available in order to proceed with the
steps in this section.
– Any parameters to configure the content of the report must be known and
should be accessible as parameters to the dashboard's URL.
Once the above pre-requisites have been satisfied, proceed with the following steps:
1. Assume the following example scenario when following the steps:
■ A contextual report called "Item Metrics" showing information about an item
is to be added to the Allocation Maintenance Flow's main page. When the user
selects an item on the page, the report will show information for the selected
item.
■ Retail Application has provided the following information about the
contextual business event:

Contextual Area
Event Name Task Flow Page Model XML Location Generated when… Payload Values
AllocMaintItem AllocMaintFlo AllocMaintPag EAR name -> war The user selects an ■ selectedItem -
SelectedEvent w e name-> jar name -> item on the the item
/oracle/retail/apps/ Allocation selected by
xyz/AllocMaintFlow Maintenance Flow's the user.
ContextualAreaMode main screen. Always
l.xml generated.
■ selectedItemType
- the type of
item. Can be
"regular" or
"pack".
Optional. If
not supplied,
assume item
is a regular
type.
■ The Item Metrics report was built in the retailer's BI reporting tool (e.g. Oracle
BI EE). It was built considering the payload values the contextual business
event will generate.
2. Open the Custom Shared Library workspace in JDeveloper.
3. Open the task flow contextual area model XML file (ex.
ViewController/src/custom/AllocMaintFlowContextualAreaModel.xml).
4. Add an <Item> element within the topmost <Items> element that references the
task flow called ViewContextAwareReportFlow. The
ViewContextAwareReportFlow is a framework for rendering URL based reports
that will be aware of contextual business events emanating from the Retail
Application task flows.
Example:
<Items>
...
...
<Item id="showItemMetric"
type="taskflow"
title="Item Metric">
<url>
/WEB-INF/oracle/retail/apps/framework/contextawarereport/publicui/flow/ViewCont
extAwareReportFlow.xml#ViewContextAwareReportFlow
</url>
</Item>
</Items>
Note the following:

■ Make sure that the <Item> id is unique.
■ Make sure the <Item> type is "taskflow"
■ Provide a meaningful title.

5. Populate the parameters to the ViewContextAwareReportFlow by adding the

following <Parameter>/<Parameters> elements.
<Items>
<Item id="showCustomerMetric"
type="taskflow"
title="Customer Metric">
<url>
/WEB-INF/oracle/retail/apps/framework/contextawarereport/publicui/flow/ViewCont
extAwareReportFlow.xml#ViewContextAwareReportFlow
</url>
<Parameters>
<Parameter id="reportDescription">Item Metric</Parameter>
<Parameter
id="actionType">AllocMaintItemSelectedEvent</Parameter>
<Parameter id="primaryUrl">
<![CDATA[/faces/oracle/retail/apps/framework/contextawarereport/publicui/page/V
iewContextAwareReportTestPage.jspx?paramItemId=<selectedItemId>&paramItemType=<
selectedItemType:token01>&paramLanguage=<language>]]>
</Parameter>
<Parameter id="token01">regular</Parameter>
</Parameters>
</Item>
</Items>
Note the following:

■ The <Parameter id="reportDescription"> element is the title of the contextual
area report. Set this to a meaningful value.
■ The <Parameter id="actionType"> element indicates the contextual business
event name the report will listen to.
■ The <Parameter id="primaryUrl"> element indicates the URL to the contextual
area report in the BI server. The entire URL must be marked as character
data (e.g. enclosed in CDATA). Note that the parameters to the URL are
tokenized. The example above uses a test page called
ViewContextAwareReportTestPage.jspx which can be replaced with the actual
report URL.
– The "?paramItemId=<selectedItemId>" portion of the URL instructs the
system to pass the contextual business event payload value called
selectedItemId into the URL parameter paramItemId when rendering the
contextual report.
– The "?paramItemType=<selectedItemType:token01>" portion of the URL
instructs the system to pass the contextual business event payload value
called selectedItemType into the URL parameter paramItemType when
rendering the contextual report. If that payload value is empty or null at
runtime, then a default value of regular is used as referenced in a
<Parameter id="token01"> entry. The colon symbol separates the payload
value from the default value if the payload value is null.

– The "?paramLanguage=<language>" portion of the URL instructs the

system about the current locale of the user. The "language" identifier is a
reference to a value in the contextual event payload. This is a built-in
value that all Retail Application contextual business event payloads will
have.
■ The <Parameter id="token01"> element holds the default value for the URL
parameter selectedItemType. Token parameters hold default values and you
can define up to 20 default value tokens.
7. Test the Retail Application. Go to the flow where the report was added and verify
that the report is rendered correctly.
Adding a DVT Taskflow based Contextual Report

Before adding a DVT taskflow based contextual report, the retailer must have:
■ Built, prepared, deployed, and tested the Custom Shared Library as described in
the section Preparing the Custom Shared Library for Adding Contextual Reports.
■ Obtained information about the Retail Application's list of contextual business
events that can be broadcast from various workflows.
■ Created one or more taskflows using the ADF DVT components.
– Any parameters to configure the content of the report must be known and
should be accessible as taskflow parameters.
Once the above pre-requisites have been satisfied, proceed with the following steps:
1. Assume the following example scenario when following the steps:
■ A contextual report called "Item Metrics" showing information about an item
is to be added to the Allocation Maintenance Flow's main page. When the user
selects an item on the page, the report will show information for the selected
item.
■ Retail Application has provided the following information about the
contextual business event:

Contextual Area
Event Name Task Flow Page Model XML Location Generated when… Payload Values
AllocMaintItem AllocMaintFlo AllocMaintPag EAR name -> war The user selects an ■ selectedItem -
SelectedEvent w e name-> jar name -> item on the the item
/oracle/retail/apps/ Allocation selected by
xyz/AllocMaintFlow Maintenance Flow's the user.
ContextualAreaMode main screen. Always
l.xml generated.
■ selectedItemType
- the type of
item. Can be
"regular" or
"pack".
Optional. If
not supplied,
assume item
is a regular
type.
■ The Item Metrics report was built in ADF. It was built considering the payload
values the contextual business event will generate.
3. Changes Required in Shared Library Registry for Custom DVT Taskflow based
Contextual Report
a. Obtain the task flow contextual area model XML file (ex.
ViewController/src/custom/AllocMaintFlowContextualAreaModel.xml).
b. Add an <Item> element within the topmost <Items> element that references
the task flow called DVTContextAwareReportFlow. The
DVTContextAwareReportFlow is a framework for rendering ADF DVT based
reports that will be aware of contextual business events emanating from the
Retail Application task flows.
Example:
<Items>
...
...
<Item id="showItemMetric"
type="taskflow"
title="Item Metric">
<url>
/WEB-INF/oracle/retail/apps/framework/dvtcontextawarereport/publicui/flow/D
VTContextAwareReportFlow.xml#DVTContextAwareReportFlow
</url>
</Item>
</Items>
Note the following:

- Make sure that the <Item> id is unique.

- Make sure the <Item> type is "taskflow"
- Provide a meaningful title.
c. Populate the parameters to the DVTContextAwareReportFlow by adding the
following <Parameter>/<Parameters> elements.
<Items>
<Item id="showCustomerMetric"
type="taskflow"
title="Customer Metric">
<url>
/WEB-INF/oracle/retail/apps/framework/dvtcontextawarereport/publicui/flow/D
VTContextAwareReportFlow.xml#DVTContextAwareReportFlow
</url>
<Parameters>
<Parameter
id="taskflowURL">/WEB-INF/oracle/retail/apps/framework/uishell/navigation/c
ontextualarea/flow/ItemMetricFlow.xml#ItemMetricFlow</Parameter>
<Parameter id="parameterName1">itemId</Parameter>
<Parameter id="payloadKeyName1">ItemId</Parameter>
<Parameter
id="parameterValue1">#{payload.valueMap['ItemId']}</Parameter>
<Parameter id="refreshOnDisclosure">#{true}</Parameter>
</Parameters>
</Item>
</Items>
Note the following:

- The <Parameter id="taskflowURL"> element is the URL of the DVT taskflow
that will be displayed in the contextual area.
- The <Parameter id="parameterName1"> element indicates a parameter for
the DVT taskflow. A maximum of 15 parameters can be specified.
- The <Parameter id="payloadKeyName1"> element indicates the name of the
payload key that maps to the taskflow parameter parameterName1. A
maximum of 15 payload keys can be specified. The value of the payload key in
the event payload will be used for the parameter in the DVT taskflow.
- The <Parameter id="parameterValue1"> element holds the default value of
the DVT taskflow. A maximum of 15 parameter values can be specified.
- The <Parameter id="refreshOnDisclosure"> element is used to refresh the
DVT taskflow on the disclosure of the tab.
4. Test the Retail Application. Go to the flow where the report was added and verify
that the report is rendered correctly.
Enabling Dynamic Task Items in the Retail Application

The Retail Application provides the capability to display both static and dynamic tasks
in the task list. The static tasks are based off an xml model file, for example,

HomeTaskMenuModel.xml, HomeReportsMenuModel.xml. These tasks should be

predefined in the tasks or reports menu model file.
The dynamic tasks can be sourced from any data source like OBIEE, BIPublisher,
database tables, Web Services etc. The complete hierarchy of task items including the
folders and actions can be generated dynamically at runtime.
From the user's perspective, there is no difference between the static versus the
dynamic task items. They look and behave the same.

The DynamicContentHandler Interface

The Retail Application provides an interface called DynamicContentHandler that can
be implemented to add dynamic tasks in the task menu. The interface is as follows
package oracle.retail.apps.framework.uishell.taskmenu.dynamiccontent.handler;
import java.util.List;
import
oracle.retail.apps.framework.uishell.taskmenu.dynamiccontent.dataobject.TaskMenuIt
em;
import
oracle.retail.apps.framework.uishell.util.RetailUiShellHttpSessionListeners;
public interface DynamicContentHandler extends

RetailUiShellHttpSessionListeners.RemovalListener {
public List<TaskMenuItem> getChildren(TaskMenuItem taskMenuItem) throws
Exception;
public List<TaskMenuItem> getDefaultTaskMenuItems() throws Exception;
public TaskMenuItem getInContextTaskMenuItem(String taskMenuItemId) throws

Exception;
}
The interface extends another interface called

RetailUiShellHttpSessionListeners.RemovalListener. The RemovalListener interface
provides the following method.
public static interface RemovalListener extends Serializable {
public void onSessionRemove();
}
The below table explains the use of these methods.
getChildren(TaskMenuItem This method provides the child task items for a given task
taskMenuItem) menu item.
getDefaultTaskMenuItems() This method provides the task items that will be loaded as
the default content in the Retail Application.
getInContextTaskMenuItem(String This method provides the task item based on a given task
taskMenuItemId) menu id for In-Context launching.
onSessionRemove() This method will be called by the Retail Application when
the user logs out of the application. The method can be
used to do any resource cleanup or can be used to logout
from the external data source.
DynamicContent Type
The Item element of the menu model file supports a type called 'dynamicContent'
along with the type's taskflow and link. When the Retail Application encounters the
type as dynamicContent, it looks for the attribute called dynamicContentHandler. The
dynamicContentHandler attribute will tell the Retail Application the name of the
implementation class which will be used to provide the dynamic task items. The class
should implement the DynamicContentHandler interface.
<Item id="customDynamicMenuFolder" visible="#{true}" title="Custom Dynamic Menu"
type="folder">
<Items>

<Item id="customTreeModelDynamicContent" title="Custom Dynamic

Menu"
type="dynamicContent"
dynamicContentHandler="oracle.retail.apps.framework.uishell.taskmenu.handler.custo
m.CustomTreeModelDynamicContentHandler"
visible="#{securityContext.authenticated}"/>
</Items>
</Item>
The Item element with the type attribute as dynamicContent can be placed anywhere
in the hierarchy of the static task items in the tasks or reports menu model file. The
dynamic task items will begin exactly from the location where the dynamicContent
Item is defined.
The menu model file can be customized to add an entry for the dynamic content as
shown above. Please refer to the section Adding or Modifying an Item in the Tasks
Menu for more details.
Example Implementation of the DynamicContentHandler Interface

We will start with a simple example to show how to display the dynamic task items in
the task menu. The example uses the org.apache.myfaces.trinidad.model.TreeModel
implementation called
org.apache.myfaces.trinidad.model.RowKeyPropertyTreeModel to pull and display
data in the task menu hierarchy. The class
org.apache.myfaces.trinidad.model.RowKeyPropertyTreeModel is a subclass of
org.apache.myfaces.trinidad.model. ChildPropertyTreeModel. The class
ChildPropertyTreeModel creates a TreeModel from a list of beans and the class
RowKeyPropertyTreeModel adds the support of row keys to the TreeModel. Let's
assume that we have a TreeModel object created for a hierarchy of Employee objects.
We want to display the names of the employees as tasks in the task list. The managers
will be displayed as folders. The action on the manager's name will open the list of
directs for the manager. The action on the leaf employee names will open the
employee details screen for the selected employee.
The implementation class for the DynamicContentHandler interface is named as
CustomTreeModelDynamicContentHandler. It has a method that builds the TreeModel
from the list of Employee objects.
/**
* Build a custom tree model.
* @return
*/
private TreeModel buildTreeModel() {
List<Employee> allEmployees = new ArrayList<Employee>();
Employee manager1 = new Employee(197, "Kevin Feeny");

Employee emp = new Employee(198, "Donald OConnel");
manager1.addDirect(emp);
emp = new Employee(199, "Douglas Grant");
Employee manager2 = new Employee(200, "Jennifer Whalen");

emp = new Employee(201, "Michael Harstein");
Employee manager3 = new Employee(203, "Susan Marvis");
emp = new Employee(202, "Pat Fay");

manager2.addDirect(manager3);
emp = new Employee(204, "Hermann Baer");
allEmployees.add(manager1);
allEmployees.add(manager2);
allEmployees.add(emp);
//create a RowKeyPropertyTreeModel with employeeId as a row key and

directs as child property
return new RowKeyPropertyTreeModel(allEmployees, "directs", "employeeId");
}
The TreeModel is initialized on the initialization of the class

CustomTreeModelDynamicContentHandler.
public class CustomTreeModelDynamicContentHandler implements
DynamicContentHandler {
private static final ADFLogger LOG =

ADFLogger.createADFLogger(CustomTreeModelDynamicContentHandler.class);
private TreeModel treeModel;
private static final String TASKMENU_ITEM_ID_SEPARATOR = "_";
public CustomTreeModelDynamicContentHandler() {
super();
this.treeModel = buildTreeModel();
}
We will implement the getChildren method of the DynamicContentHandler interface.

/**
* This method is called by the Retail Application to get the dynamic task
items.
* @param taskMenuItem
* @return
*/
public List<TaskMenuItem> getChildren(TaskMenuItem taskMenuItem) {
//if taskMenuItem is null then framework is trying to load the root
objects,
//otherwise the framework has already navigated the tree
if (taskMenuItem != null) {
this.treeModel.setRowKey(taskMenuItem.getPath());
this.treeModel.enterContainer();
this.treeModel.setRowIndex(0);
} else {
this.treeModel.setRowKey(null); //move to root
}
return getChildrenForCurrentRowKey();
}
/**
* This method returns the children for the current row key in the tree model.
* @param model
* @return
*/
private List<TaskMenuItem> getChildrenForCurrentRowKey() {
List<TaskMenuItem> childTaskMenuItemList = new ArrayList<TaskMenuItem>();
int rowCount = this.treeModel.getRowCount();
for (int i = 0; i < rowCount; i++) {

this.treeModel.setRowIndex(i);
TaskMenuItem childTaskMenuItem = buildTaskMenuItem();
if (childTaskMenuItem != null)
childTaskMenuItemList.add(childTaskMenuItem);
}
return childTaskMenuItemList;
}
The Retail Application will instantiate the class

oracle.retail.apps.framework.uishell.taskmenu.handler.custom.CustomTreeModelDyn
amicContentHandler. It will cache the class for subsequent requests after instantiating
it once.
On the initial load of the page, the Retail Application will call getChildern on the
dynamicContentHandler implementation class by passing it a null value of the
TaskMenuItem object.
When the argument is null, the method getChildern should return the root dynamic
task items. The Retail Application will display the root items on the initial load of the
page. In the example above, the employees Kevin, Jennifer and Hermann are the root
items of the TreeModel so they will be loaded by the Retail Application and displayed
as the initial dynamic task items for the CustomTreeModelDynamicContentHandler.
When the user clicks on a Folder, the Retail Application will send the current selected
TaskMenuItem object to the getChildern method to load the children of the current
selected task item. When the argument of the getChildren method is a valid
TaskMenuItem object, the getChildren method should return the children of the
TaskMenuItem object.
The Retail Application always lazy loads the dynamic items. This means that the
children of a dynamic Folder will only be loaded when the user clicks on the Folder.
Once the children are loaded they are cached by the Retail Application. In the above
example, even though the Retail Application lazy loads the dynamic items, the
TreeModel pre-loads all the employees.
TaskMenuItem class
The TaskMenuItem class is an abstraction of a dynamic task in the task menu. It is an
equivalent of the 'Item' element in the task menu model file. The TaskMenuItem class

can be used to add dynamic links, taskflows and folders in the task menu. The class
has the following attributes.
private Object path;
private String id;
private String title;
private String url;
private String shortDesc;
private boolean visible = true;
private TaskMenuItemType type = TaskMenuItemType.LINK;
private TaskMenuTarget target;
private List<Parameter> parameters;
private List<Attribute> attributes;
private String accessKey;
private boolean disabled;
Following is a java doc screenshot of the TaskMenuItem class.
The attribute 'path' can be used to store the information of the current node. The 'path'
attribute is of type 'Object' so it can store any object which can be used to identify the
current node in the external hierarchy. In the example above, the path stores the row
key of the TreeModel which is an ArrayList of employeeId's starting from the root to
the current selected node. The path can vary based on the implementation of the
DynamicContentHandler interface. For example, if the DynamicContentHandler

implementation reads the database tables to display a dynamic menu then the path
can be an ArrayList of the primary keys of the database tables, if the
DynamicContentHandler implementation calls an external web service to generate a
dynamic menu then the path can be a String object which identifies a node in the
external system.
The following code snippet shows how a TaskMenuItem can be built in the
DynamicContentHandler implementation class.
/**
* build a task menu item from the custom object.
* @param rowKey
* @param employee
* @return
*/
private TaskMenuItem buildTaskMenuItem() {
List<Object> rowKey = (List<Object>)this.treeModel.getRowKey();

Employee employee = (Employee)this.treeModel.getRowData();
if (this.treeModel.isContainer()) {
return buildContainerTaskMenuItem(rowKey, employee);
} else {
return buildLeafTaskMenuItem(rowKey, employee);
}
}
/**build container taskmenu item.

* @param rowKey
* @param employee
* @return
*/
private TaskMenuItem buildContainerTaskMenuItem(List<Object> rowKey, Employee
employee) {
TaskMenuItem taskMenuItem = new TaskMenuItem();
taskMenuItem.setPath(rowKey);
taskMenuItem.setId(generateUniqueId(rowKey));
taskMenuItem.setTitle(employee.getName());
taskMenuItem.setShortDesc(employee.getName() + " : " +
employee.getEmployeeId());
taskMenuItem.setType(TaskMenuItem.TaskMenuItemType.FOLDER);
return taskMenuItem;
}
/**build leaf task menu item.

* @param rowKey
* @param employee
* @return
*/
private TaskMenuItem buildLeafTaskMenuItem(List<Object> rowKey, Employee
employee) {
TaskMenuItem taskMenuItem = new TaskMenuItem();
taskMenuItem.setPath(rowKey);
taskMenuItem.setId(generateUniqueId(rowKey));
taskMenuItem.setTitle(employee.getName());
taskMenuItem.setShortDesc(employee.getName() + " : " +
taskMenuItem.setType(TaskMenuItem.TaskMenuItemType.TASKFLOW);
taskMenuItem.setUrl("/WEB-INF/oracle/retail/apps/framework/uishell/navigation/cont
entarea/flow/TestOverrideCloseTabFlow.xml#TestOverrideCloseTabFlow");

//set attributes on taskMenuItem

taskMenuItem.setAttribute("TabTitle",
employee.getName() + " : " +
taskMenuItem.setAttribute("tabShortDesc",
"Employee " + employee.getName() + " has emplyee
Id " +
employee.getEmployeeId() + ".");
//set parameters on taskMenuItem

taskMenuItem.setParameter("EmployeeId",
String.valueOf(employee.getEmployeeId()));
return taskMenuItem;
}
/**This method generages a unique id for the taskmenu item.

* @param rowKey
* @return
*/
private String generateUniqueId(List<Object> rowKey) {
return rowKey.stream().map(c ->
c.toString()).collect(Collectors.joining(TASKMENU_ITEM_ID_SEPARATOR));
}
Default Dynamic Task Items

When a user logs in the Retail Application, the user sees the default content that has
been configured in the Retail Application. The default content opens up directly in a
Retail UIShell tab without the user having to launch it from the task menu. The
dynamic task items can also be configured as the default content in the application.
The DynamicContentHandler interface provides a method called
getDefaultTaskMenuItems which returns a List of TaskMenuItem objects. The items
returned from this method will be launched automatically after the user logs in.
The following is a sample implementation of the getDefaultTaskMenuItems method.
/**Get the default task menu items. These will be automatically loaded on
initial load of the home page.
* @return
*/
@Override
public List<TaskMenuItem> getDefaultTaskMenuItems() {
List<Object> rowKey = new ArrayList<Object>();
rowKey.add(200); //"Jennifer Whalen"
rowKey.add(203); //"Susan Marvis"
rowKey.add(202); //"Pat Fay"
Employee employee = (Employee)this.treeModel.getRowData(rowKey); //get Pat
Fay
TaskMenuItem taskMenuItem = buildLeafTaskMenuItem(rowKey, employee);

List<TaskMenuItem> defaultTaskMenuItems = new ArrayList<TaskMenuItem>();
defaultTaskMenuItems.add(taskMenuItem);
return defaultTaskMenuItems;
}
In-Context Launch of Dynamic Task Items

The Retail Application provides a way to launch links and taskflows directly using a
browser URL. The content is launched in the context of the external application by
passing parameters in the URL.

The Retail Application requires a navModelItemId parameter in the request to identify

the content that needs to be launched. The Retail Application checks the static task
menu model files to see if an Item exists with that id in the model file. If the Retail
Application does not find a static item, it consults the list of dynamic content handlers
configured with the application to look for the item. If the dynamic content handler
returns a TaskMenuItem for the given id, it will be launched in the Retail Application.
The dynamic content handler should implement a method called
getInContextTaskMenuItem(String taskMenuItemId) which will return the
TaskMenuItem object for the taskMenuItemId received. The
getInContextTaskMenuItem should be able to find the Item using the taskMenuItemId.
The following is a sample implementation of the getInContextTaskMenuItem(String
taskMenuItemId) method.
/**This method returns an in-context item.
* @param taskMenuItemId
* @return
*/
@Override
public TaskMenuItem getInContextTaskMenuItem(String taskMenuItemId) {
TaskMenuItem inContextTaskMenuItem = null;
Employee employee = null;
List<Object> rowKey = null;
if (taskMenuItemId != null) {
try {
rowKey =
Arrays.stream(taskMenuItemId.split(TASKMENU_ITEM_ID_
SEPARATOR)).map(c -> Integer.valueOf(c)).collect(Collectors.toList());
employee = (Employee)this.treeModel.getRowData(rowKey);
if ((employee != null) && (employee.getDirects().isEmpty())) {

inContextTaskMenuItem = buildLeafTaskMenuItem(rowKey,
employee);
}
} catch (Exception e) {
if (LOG.isWarning()) {
LOG.warning("Error occurred looking for dynamic In-Context
Item with id " +
taskMenuItemId, e);
}
}
}
return inContextTaskMenuItem;
}
The custom dynamic content handler can be added to the classpath of the Retail
Application by deploying it as a shared library. Please refer to the section Adding a
Custom Shared Library for details on how to deploy a shared library.
Report Adapters
The DynamicContentHandler interface can be used to add dynamic task items in the
task menu from a variety of data sources including OBIEE, BIPublisher, database
tables, and custom Web Services etc. The Retail Application provides the default
implementation of the DynamicContentHandler interface for OBIEE and BIPublisher.
These implementations are called Report Adapters. The Report Adapters can display
the user's reports from OBIEE and BIPublisher as tasks in the task list. The user can
click on the tasks to display individual reports and dashboards.

Note: The connection to both the OBIEE and BIPublisher should be

secured using TLS protocol. Please ensure that the Report Adapter
integration is done using secured protocol in the production
environments.
OBIEE Report Adapter

The RetailAppsObieeAdapter relies on a properties file called
RetailAppsObieeAdapter.properties for the OBIEE configuration. Create
RetailAppsObieeAdapter.properties in any location on the file system. Modify the
setDomainEnv.cmd for the Windows environment or setDomainEnv.sh file for the
Unix environment to add the RetailAppsObieeAdapter.properties as a Java system
property specifying the location in the file system where the
RetailAppsObieeAdapter.properties file resides.
For example for windows environment
set EXTRA_JAVA_
PROPERTIES=-DRetailAppsObieeAdapter.properties=D:\Work\RetailAppsFramework\RetailA
ppsObieeAdapter.properties %EXTRA_JAVA_PROPERTIES%
For Unix environment
EXTRA_JAVA_PROPERTIES="-DRetailAppsObieeAdapter.properties
=/scratch/u00/product/Oracle/Middleware/user_projects/domains/RAFDomain/custom_
properties/RetailAppsObieeAdapter.properties ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES
The RetailAppsObieeAdapter.properties can be used to specify the following

properties for the OBIEE Report Adapter configuration.
Property Required? Description

bi.connection.name Yes This property is used to specify the name
of the BISoapConnection used to display
the OBIEE reports. The connection should
be created using the Enterprise Manager.
Please refer to the section Creating the
BIConnection for more details.
bi.bipublisher.context.path No If the OBIEE installation includes both the
OBIEE analytics and BIPublisher then the
BIPublisher reports can also be displayed
using the RetailAppsObieeAdapter. The
bi.bipublisher.context.path is used to
specify the context root of the BIPublisher
installation. The default value is
xmlpserver.
bi.external.integration No This property can be used to disable the
RetailAppsObieeAdapter integration.
Setting this to false will disable the
RetailAppsObieeAdapter integratioin. The
default value is true.
bi.report.new.browser.tab No This property can be used to display the
OBIEE reports in a new browser tab on in a
new Retail UI Shell tab. The default
behavior of the RetailAppsObieeAdapter is
to open the OBIEE reports in a new
browser tab. Setting this property to false
opens the reports in a new UI Shell tab.
The default value is true.

Creating the BIConnection

Please follow the following steps to create the BIConnection for the
RetailAppsObieeAdapter configuration.
1. Login to the Enterprise Manager of the environment where the Retail Application
is deployed and go to 'System MBean Browser' as shown below.
2. Go to 'Application Defined MBeans' and its sub folder

'oracle.adf.share.connections'
3. Expand 'Application: <AppName>' and select 'ADFConnections'. The following

example uses RetailAppsFrameworkTest as the AppName.

4. Go to the 'Operations' tab and click 'createConnection'.
5. Enter Connection Type as BISoapConnection and Connection Name as

BIConnection. Click Invoke on top right.
6. Refresh the tree using the button 'Refresh cached tree data'.

7. Once the tree is refreshed, you will notice that 'ADFConnections' becomes a folder
and it has a new connection 'BIConnection'. Click on the BIConnection to open its
properties in the right pane.
8. Enter the values shown in the table below. Once done click Apply on the top right.
Context The context root of the Oracle BI EE

installation. Example: analytics
Host The host of the Oracle BI EE installation.
IsStaticResourcesLocationAutomatic The IsStaticResourcesLocationAutomatic
attribute can be either true or false. When
this attribute is true, the BI Presentation
Server will be used to specify the location
of the static resources. When this attribute
is false, the attribute
'StaticResourcesLocation' should be
provided. The attribute
StaticResourcesLocation will be used to
find the static resources when the attribute
IsStaticResourcesLocationAutomatic is
false.
Password The password for the BIImpersonateUser.
Port The port of the Oracle BI managed server.
Example 9704

Protocol http or https

For production environments, use https.
ShouldPerformImpersonation true (keep it true, default is true)
StaticResourcesLocation The path of the location where the static
resources are available.
If the IsStaticResourcesLocationAutomatic
attribute is true then use the following
URL for the StaticResourcesLocation
attribute.
http://<obiee_host>:<obiee_
port>/analytics
If the IsStaticResourcesLocationAutomatic
attribute is false, then use the following
URL for the StaticResourcesLocation
attribute.
http://<web_tier_host>:<web_tier_
port>
The Oracle BI EE static resources, namely
the 'res' and 'analyticsRes' directories
should be available from the Oracle Web
Tier's htdocs directory when the
IsStaticResourcesLocationAutomatic
attribute is false.
Username The username that has been configured on
the Oracle BI EE with the impersonate
permissions.
Example: BIImpersonateUser
WSDLContext analytics-ws
9. Go to 'ADFConections' to save the changes. Click on 'save' operation in the

Operations tab.
10. Click on 'Invoke' on the top right to save the changes.

Once the connection is created successfully, modify the

RetailAppsObieeAdapter.properties to add the bi.connection.name as BIConnection.
Configuring the Reports Menu

Once we have configured the RetailAppsObieeAdapter.properties and created a
BIConnection, we can add an Item of type="dynamicContent" in the
HomeReportsMenuModel.xml file to display the OBIEE Reports in the Reports menu.
The implementation of the DynamicContentHandler interface for OBIEE is called
oracle.retail.apps.framework.report.obiee.handler.ObieeDynamicContentHandler.
<Item id="obieeFolder" visible="#{true}" title="OBIEE" type="folder">
<Items>
<Item id="obieeDynamicContent" title="OBIEE Dynamic Menu"
dynamicContentHandler="oracle.retail.apps.framework.report.obiee.handler.ObieeDyna
micContentHandler"
</Items>
</Item>
The reports menu model can be customized to add an entry for the dynamic content as
shown above. Please refer to the section Adding or Modifying an Item in the Reports
BIPublisher Report Adapter

The RetailAppsBiPublisherAdapter relies on a properties file called
RetailAppsBiPublisherAdapter.properties for the BIPublisher configuration. Create
RetailAppsBiPublisherAdapter.properties in any location on the file system. Modify
the setDomainEnv.cmd for the Windows environment or setDomainEnv.sh file for the
Unix environment to add the RetailAppsBiPublisherAdapter.properties as a Java
system property specifying the location in the file system where the
RetailAppsBiPublisherAdapter.properties file resides.
For example for windows environment:
set EXTRA_JAVA_
PROPERTIES=-DRetailAppsBiPublisherAdapter.properties=D:\Work\RetailAppsFramework\R
etailAppsBiPublisherAdapter.properties %EXTRA_JAVA_PROPERTIES%
For Unix environment:

EXTRA_JAVA_
PROPERTIES="-DRetailAppsBiPublisherAdapter.properties=/scratch/u00/product/Oracle/
Middleware/user_projects/domains/RAFDomain/custom_
properties/RetailAppsBiPublisherAdapter.properties ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES

The RetailAppsBiPublisherAdapter.properties can be used to specify the following

properties for the BIPublisher Report Adapter configuration.
Property Required? Description

bipublisher.wsdl.location Yes This property is used to specify the WSDL
URL of the BIPublisher
PublicReportService. For example:
https://bipublisher_host:bipublisher_
port/
xmlpserver/services/PublicReportService
?wsdl
bipublisher.external.integra No This property can be used to disable the
tion RetailAppsBiPublisherAdapter
integration. Setting this to false will disable
the RetailAppsBiPublisherAdapter
integratioin. The default value is true.
bipublisher.report.new.bro No This property can be used to display the
wser.tab BIPublisher reports in a new browser tab
on in a new Retail UI Shell tab. The default
behavior of the
RetailAppsBiPublisherAdapter is to open
the BIPublisher reports in a new browser
tab. Setting this property to false opens the
reports in a new UI Shell tab. The default
value is true.
Store the BIPublisher Admin Credentials

The RetailAppsBiPublisherAdapter requires the admin credentials of the BIPublisher
to be stored in the WebLogic domain credential store where the Retail Application is
deployed. The admin credentials are used by the RetailAppsBiPublisherAdapter to
connect to the BIPublisher.
The admin credentials can be stored the in domain credential store by using WebLogic
Scripting tool or the Enterprise Manager.
WebLogic Scripting Tool

After running the wlst script, connect to the WebLogic Domain using the connect()
command and run the following createCred() command. Replace the <bip_admin_
user> and <bip_admin_password> with the BIPublisher admin user and password.
createCred(map="oracle.retail.apps.framework.report.bipublisher", key="bipadmin",
user="<bip_admin_user>", password="<bip_admin_password>", desc="BIPublisher admin
user credentials")
If the credentials already exist for the map

'oracle.retail.apps.framework.report.bipublisher' and key 'bipadmin', update them
using the following command
updateCred(map="oracle.retail.apps.framework.report.bipublisher", key="bipadmin",
user="<bip_admin_user>", password="<bip_admin_password>")
Enterprise Manager
1. Navigate to Security/Credentials.

2. Create a new map called 'oracle.retail.apps.framework.report.bipublisher'. Inside

this map create a new key called 'bipadmin' and enter the BIPublisher admin
credentials.
Configuring the Reports Menu

Once we have configured the RetailAppsBiPublisherAdapter.properties and have
added the BIPublisher WSDL URL property in the properties file, we can add an Item
of type="dynamicContent" in the HomeReportsMenuModel.xml file to display the
BIPublilsher Reports in the Reports menu. The implementation of the
DynamicContentHandler interface for the BIPublisher is called
oracle.retail.apps.framework.report.bipublisher.handler.BiPublisherDynamicContentH
andler.
<Item id="bipublisherFolder" visible="#{true}" title="BiPublisher"
type="folder">
<Items>
<Item id="bipublisherDynamicContent" title="BIPublisher Dynamic
Menu"
dynamicContentHandler="oracle.retail.apps.framework.report.bipublisher.handler.BiP
ublisherDynamicContentHandler"
</Items>

</Item>
The reports menu model can be customized to add an entry for the dynamic content as
shown above. Please refer to the section Adding or Modifying an Item in the Reports


8
Functional Design
8
This chapter discusses the various functional aspects of Oracle Retail Allocation. The
chapter provides the following:
■ A functional overview of the system, along with its features and corresponding
functional assumptions.
■ The sources of data used by rules to determine gross need.
■ A description of the three possible methods of closing allocations.
Functional Features and Assumptions

This section covers what Allocation does, different item sources, and the functional
assumptions that are made during the creation of ASN-based allocations, item-location
combination validation, calculation multiple, what-if allocations, weight and date
selection, and proportional allocations.
Note: Oracle Retail Allocation does not offer logic to support the
following:
■ Fashion items set up as grandparent > parent > children (items)
■ Buyer packs where the packs are not inventoried and only the
components are inventoried
Overview: What Does Oracle Retail Allocation Do?

An Allocation application should enable retailers to make important decisions as close
as possible to the time the product must be sent to the destination stores or
warehouses. A critical link in the supply chain process, the allocation process presents
the final chance to distribute products successfully. The challenges facing retailers for
allocating product are the same, whether they sell fashion items, groceries or hard
lines. Merchants want an efficient, accurate method of translating their merchandise
plans into location level allocations. Effectively allocating products is a critical step in
product life cycle management and the last chance the retailer has to get the right
product to the right location in the right quantity.
Oracle Retail Allocation enables retailers to take advantage of the most current,
up-to-date sales and inventory information. The application also has the flexibility to
allow allocations to be calculated months in advance for vendor commitment
purposes.
Oracle Retail Allocation has been designed to address the following challenges (among
others) related to the correct allocation of product:
Functional Design 8-1

■ How to put a variety of merchandise plans into action.

■ How to allocate products to support diverse marketing efforts and selling profiles.
■ How to effectively and accurately allocate products without increasing headcount
while continuing to grow the business.
■ How to streamline the training process for allocators.
If these challenges are not met, the wrong product can be sent to the wrong location in
the incorrect quantity at the wrong time. The net result is higher markdowns and
lower profits.
Oracle Retail Allocation allows multiple parameters to be selected when creating an
allocation. The system determines store or warehouse level need based on metrics that
fit the product, location characteristics and product life cycle. The result is allocations
based on individual location need, the key to maximizing sales and profits.
In Oracle Retail Allocation, the retailer has the option of executing a sales plan, receipt
plan, history or forecast at any level of the hierarchy. The retailer can allocate a
collection of products using a class plan or allocate one item using its history. Oracle
Retail Allocation has the functionality to create and reuse 'templates' to save time and
produce consistent results.
Oracle Retail Allocation can react to current trends. The system has sophisticated rules
that can compare current selling to a plan and create a forecast on which to base an
allocation. Oracle Retail Allocation provides the ability to both allocate in advance to
give vendor commitments and allocate at the last minute, utilizing up-to-date sales
and inventory information to determine individual location need. Some key features
of the application include:
■ Any PO that a user creates can be previewed through the front end.
■ In order to increase the efficiency of the allocation process, Oracle Retail Allocation
has the ability to split allocations. By splitting an allocation, the user has the option
of selecting the product hierarchy and location combinations that the user would
like to remove from the original allocation.
■ Oracle Retail Allocation can automatically respect the existence of an item location
record in RMS.
■ The user is allowed to copy an existing allocation, resulting in the creation of a
new one with the same item/location combinations and other parameters as the
source.
Item Sources
Item sources represent the physical inventory that Oracle Retail Allocation can
allocate. The system allows the retailer to allocate based upon the following:
■ Advanced shipping notices (ASN) or Advanced Shipment Notifications (ASN) are
batch communications that inform a retailer when to expect a certain quantity of
order inventory. ASN quantities are received closer to the time of arrival at the
distribution center. Allocations based upon ASN quantities allow retailers to
account for purchase order shortages or overages as a part of their Oracle Retail
Allocation process.
■ Transfers
■ Bills of lading (BOL)
■ Purchase orders
■ Warehouse-sourced inventory

■ Approved allocations to a warehouse

The user is given more access to and control of existing transactions because of these
item sources, which increases supply chain efficiencies. As a result, the next inventory
movement can be communicated to the distribution center before the inventory arrives
and is put on the shelf as warehouse stock.
How Need is Determined

The logic of Oracle Retail Allocation is based on establishing need at the item/location
level. The user determines need by choosing a rule and rule modifiers and then setting
optional quantity limits. The system accesses gross need values provided. The
application applies constraints to the data, such as on-hands and on-order, and
determines the net need. At this point, the algorithm determines how to spread the
available inventory across all of the net needs for each location, and the allocation is
created.
When attempting to allocate with a store that has a zero need, the system uses the
sister-store data instead of allocating no product. The Sister Store Setup system option
setting file allows the retailer to determine whether to use the sister store need
whenever the need is calculated as zero or only when no need records exist for each
location.
Oracle Retail Allocation retrieves most data in real-time from the Oracle Retail
Merchandising System (RMS). Oracle Retail Allocation only requires visibility to
approved items and purchase orders and transfers. See Functional and Technical
Integration in the Functional and Technical Integration chapter for integration
information.
In sum, Oracle Retail Allocation determines the needs of each individual store or
warehouse at the item-location level through the following capabilities:
■ The application sorts through large quantities of data, such as sales history, current
on-hand, and store volume groups.
■ The application applies user-established rules, rule modifiers, and optional
quantity limits.
■ The application utilizes complex algorithms that can determine gross need for
large volumes of locations and products, using real time data.
■ Presentation Minimums at the item location level can be respected.
Due to the importance of balancing the need to maintain appropriate store/warehouse
presentation level and effectively allocate to stores' or warehouses’ inventory needs,
Oracle Retail Allocation can access item/location planogram data and dictate to the
algorithm the smallest amount to allocate a given item/location.
Weight and Date User Selection
Note: In the Allocation application and in this document, the terms

'rules' and 'policies' are used interchangeably.
The premise of Oracle Retail Allocation is to establish need at the item/location level
via policies and policy modifiers. The following eight different rules are available:
■ Sales history
■ Forecast

■ Plan
■ Receipt plan
■ History and plan
■ Plan re-project
■ Corporate
■ Manual
Although these rules are detailed, occasionally the user needs to base allocations upon
like items. The User Merchandise Level Selection screen allows retailers to select any
combination of like data on which to base allocations. The user may choose a
merchandise hierarchy level, a combination of merchandise hierarchy levels,
individual items or merchandise hierarchy levels combined with individual items.
Each combination of data may be weighted. For example, an allocation may require
the input of Subclass Z’s sales history to be weighted at 50% and item A’s sales history
to be weighted at 75%. The values selected by the user are applied to each item on the
allocation.
'What if' On Hand

The 'what if' source allows the user to create hypothetical allocations. 'What if'
allocations provide users the flexibility to create purchase orders based upon the
allocation calculated quantities. The process is exactly the same as a regular allocation
except that the user starts with an infinite available number of the selected product or
a user specified quantity.
Purchase Order Addition

In Oracle Retail Allocation, the user has the ability to allocate many items on a single
allocation. This ability is dependent on what rules are utilized when gathering an item,
or set of items' need values. The user has the ability to add quantities to existing
purchase orders (POs) from the front end screen dedicated to 'what if' summary data.
Valid items added to the PO must not previously exist on the PO. If the item already
exists on the PO, the allocator should modify the quantities within the ordering
window.
The purchase order addition functionality is achieved by calling an RMS stored
procedure that handles the PO Creation Request. The Oracle Retail Merchandising
System owns this code and the standards it enforces regarding PO creation. The
current API validation includes: location exists, item exists, supplier exists,
item/supplier exists, item/supp/country exists, item is orderable and checks for dept_
level_orders which is a system option in RMS.
Holdback Quantity
The holdback quantity is the quantity that the user does not want to allocate. The
holdback quantity is subtracted from the available quantity of each item to calculate
the available percent to total quantity. The available percent of the total quantity is
applied to the gross need to determine the final allocated quantity. The following
example illustrates applying the holdback quantity to a sellable staple simple pack in
spread demand mode:
Table 8–1 Holdback Quantity Example

Dept 1 Hardware
Class 12 Tools

Table 8–1 (Cont.) Holdback Quantity Example

Subclass 123 Hand Tools
Table 8–2 Different Packs

Warehouse Net Available
Quantity Holdback Warehouse
Pack Description (Pack) Qty Qty Percent of Total
1 Hammer (5 500 75 425 425/900=47.2222%
units)
2 Screwdriver (10 350 75 275 225/900=25%
units)
3 Handsaw (15 250 0 250 250/900=27.7778%
units)
Total quantity on 1100 900
hand--------->
For sellable packs, the transaction level is the sellable unit, so sales history is recorded
at the pack level as shown in the Dept Sales column of the table below. For sellable
packs, the store owns the product at component level. When a pack is sold, the
components are deducted from the stock on hand.
Table 8–3 Dept Sales and On Hands for Sellable Packs

Rule History
Level Dept 1
Date Ranges Last 4 Weeks
Available Quantity 1500
RLOH N/A
Store Pack Dept Sales On Hands
999 1 3967 125
2 3967 140
3 3967 130
Dept Totals 3967
On hand for Sellable Packs are not recorded at the pack level through RMS, only the
pack components have on hand. Thus, on hand for sellable packs = 0. Since the final
quantity is pack quantity, the calculations do not go through any pack optimization
process in the calculation engine.
Table 8–4 The Final Calculations

OH (total
Store Gross of the
No Pack Need level) Net Need Adjusted Need
999 Pack 1 3967 0 3967 3967*47.2222%= 1873
Pack 2 3967 0 3967 3967*25%=992
Pack 3 3967 0 3967 3967*27.7778%=1102

Allocation Approval Process

The process of approving an allocation is asynchronous. The functionality is consistent
with the calculation process and allows the user to work on other allocations while one
is being submitted, reserved or approved. In addition, the validation ensures that all
inventory quantities are up to date at the time approval occurs, including the item
source quantities. This validation prevents the system from creating an allocation
against quantities that were available at the time of calculation but have since been
claimed by another allocation, process or system.
Functional Assumptions
This section covers assumptions made during ASN-based allocations, item-location
combination, calculation multiple, what-if allocations, weight and date selection, and
proportional allocations.
Advanced Shipping Notice-Based Allocation Assumptions

Oracle Retail Allocation item sources are not individually selectable. A previously
generated allocation may be selected indirectly by being included in a BOL portion of
inventory.
Item-location Assumptions
The ITEM_LOC table is where item location relationships are held and maintained
from the Oracle Retail Merchandising System.
Calculation Multiple Assumptions

■ The system assumes that all of the items under a parent have the same Store Order
Multiple (SOM) as the parent. In other words, the SOM cannot differ by item
under a parent.
■ The ability to calculate an allocation based upon one multiple and create a PO
based upon another multiple may create a discrepancy between the total amount
the allocation calculated initially, and the amount of inventory included in the
purchase order.
■ Promotional buy rounding issue: The use of the order case size as the case
multiple for PO sourced allocations creates a scenario where rounding at the inner
causes packaging discrepancies. Note that when a purchase order is the source of
an allocation, the suppliers case pack size may be different than the pack size
defined in the RMS Item data model. Because the RMS Purchase Order screen
does not hold a defined value for an inner size, the inner defined for the item may
not evenly round into the case on the purchase order.
What if
■ Front-end PO location selection only has an effect on the PO to location when the
user is creating a PO with a PO type of warehouse or cross dock, or updating a PO
with a PO type of warehouse. For all other types of PO actions, the value has no
relevance.

Note: In a typical Cross Dock scenario, if the default warehouse for a

store is also present as a destination warehouse on the What If
allocation, the user will receive a popup while trying to raise the PO
that the same warehouse cannot be specified as a source and a
destination warehouse in the same allocation and hence such a cross
dock allocation cannot be created. The PO creation will be carried out.
The user will then need to manually create an allocation using this PO
as its source.
■ The major assumption associated with this functional area is that basing the
allocation quantity on future available on hand amounts assumes that the
inventory that is expected within the warehouse arrives and that the business user
creates a separate allocation to move the inventory to the stores.
■ 'What if' allocations utilize the primary supplier's primary origin countries' inner,
case and pallet size only. If a retailer wants to use the window to create a PO to a
supplier that does not have the same multiple as the primary supplier, the
functional recommendation is to calculate the allocation and create the order using
an 'Each' multiple. The multiple can then be adjusted within the merchandising
system.
Weight and Date User Selection Assumptions

■ The many-to-one functionality is available to users when using automatic rule
types, except for corporate rules and manual.
■ The system allows the user to add the same item or merchandise hierarchy level
twice. This is intentional because various weights may be applied. Users are
responsible for adjusting the weight appropriately.
Proportional Allocation Assumption

The system assumes that a proportional allocation does not contain more than 10,000
units going to one store. The 10,000-unit value is a hard limit, and if exceeded, an
infeasible solution arises in the system's algorithm.
For both Simple and Spread Demand, the application should consider the threshold
value as the first validation for allocating quantity to the store or warehouse. This is
irrespective of whether the MIN or MAX values are mentioned.
Note: If the "Need is" set to proportional, and the threshold value
has been mentioned, allocation happens only if the store's net need is
greater than the threshold value. If the store's net need is less than the
threshold value the store is not allocated any quantity. After these
validations occur, the allocation passes through the calc engine and
the allocated quantity may be greater than the threshold value.
Scheduled Allocation Constraints

Some of the constraints the user must follow while scheduling allocations are:
■ The parent/children relationship is one parent to many children of the same
parent. The parent allocation cannot be a child allocation for another parent; a
parent allocation cannot be a parent to another parent allocation.
■ A parent allocation can only be deleted if all of the following is satisfied:

– The current date is at least one day after the scheduled end date.
– All child allocations of the parent must be closed or deleted.
– If there is at least one child allocation that is not closed or deleted or if the end
date is not met, the user cannot delete the parent allocation. The following
error message is displayed "Allocation cannot be deleted until after the
scheduled End Date and all its Child Allocation(s) are 'Deleted' and/or
'Closed'." In order to delete this parent, the user must go into the parent
allocation to change the end date and also change the status of the child or
children allocation(s) to 'deleted.'
■ It is recommended to have no more than 10 items in a scheduled allocation.
Batch Job Considerations for Scheduled Allocations

The user has to consider the following points while running the batch for scheduled
allocations:
■ Batches can be run by external scheduling system such as APPWORX or a simple
UNIX CRON job.
■ If the server is down and restarted outside the client-designated window,
scheduled allocations for that day are not created.
■ The Schedule Allocation batch must be run after RMS updates the sales and on
hand data.
■ The Daily Cleanup batch process deletes the data from the temporary tables on a
daily basis. Run this batch immediately after you run the Schedule Allocation
batch.
■ There should be a two hour window in which the child allocations can be
generated. The user has to define this two hour window and this is against the
system (server) date and timestamp that would apply to all users regardless of
time zone.
■ Whatever may be the status of the parent allocation, the batch process runs if the
parent allocation has to generate a child allocation on that day. Despite having a
status of 'Schedule Error' the parent allocation runs because the error may have
occurred in the past (when the previous batch was run), and that situation may not
be applicable for subsequent batches. The error may have occurred because of
insufficient inventory, but by the next batch run, the warehouse may have received
additional goods to meet inventory criteria, so the previous error is no longer
valid.
■ If the user tries to run the batch process a second time on the same day that the
user deleted the earlier created child allocation, the batch process does not pick up
the parent allocation, and creates the second child. The user has to either manually
create an allocation or wait for the next scheduled batch run.
Additional Validations for Scheduled Allocation

Children allocations are not created if the parent allocation has errors. The child
allocation is not created for the parent allocation, if the following validations fail:
■ At least one item has a valid item/store or item/warehouse association. For
example: If two items and two stores are selected in the Parent Allocation, then at
least one item should have association with at least one store.
■ At least one store is not closed and has a valid Warehouse-Store relationship when
the “Enforce Supply Chain” check box is selected.

■ If the Parent Allocation contains fashion items, then all the fashion items should
have Size Profile information available for all the stores if the 'Enable Size Profile'
= True in the Properties File on the System Properties tab of the system options
screen.
■ If at least one item has the warehouse available quantity greater than the
minimum available quantity specified on the “Item Review” screen of the
application, the child allocation is created with the status as 'Submitted'. This
status overrides the status specified by the user. If all items do not have the
warehouse available quantity greater than the minimum available quantity, then
no child allocation is created for that parent on that day. The status of the parent
allocation will be set to 'Schedule Error'.
■ For a warehouse to warehouse ranging checks for the Enforce Supply Chain
checkbox is in the checked state. The destination warehouse has s source method
set to Warehouse and the source warehouse of the allocation set of items being
allocated in order to receive goods from the warehouse location. If that is not set,
then the default warehouse column will be checked next. If there is no source
warehouse defaulted for the destination warehouse in either of these places, the
warehouse would be listed at the item/location level in the Item Location
Exclusions screen with the Reason Code set to Default Warehouse Missing.
Allocation Status
Significant functionality is attached to the status numbers in the system. The tables
below reflect the status column on the ALC_ALLOC table.
Table 8–5 Visible Through the User Interface

Status Description Status #
Worksheet The allocation is in the initial stages of creation 0
or it is being updated by the user.
Submitted The allocation has been submitted 1
successfully.
Approved The allocation has been approved successfully. 2
The allocation records have been sent to the
merchandising system and the other
downstream applications.
Processed The warehouse system has started executing 3
this allocation. The allocation cannot be
updated.
Closed The allocation has been executed by the 4
warehouse. The inventory movement is
complete.
Cancelled The allocation has been cancelled by an 5
external system. The allocation cannot be
updated.
Reserved The allocation has been reserved successfully. 6
The allocation records have been sent to the
merchandising system.

Table 8–5 (Cont.) Visible Through the User Interface

PO Created This status exists for 'what if' allocations only. 10
A purchase order has been created within this
'what if' allocation. The user cannot edit
anything within the allocation except creating
or updating additional purchase orders for
other items in the allocation for which no
order has been created so far.
Scheduled The allocation is scheduled. This status is not 11
dependant on whether the parent allocation is
successfully validated or not. It is a static field
and does not get updated. Child allocations
display the status selected in the Auto
Schedule screen of the parent allocation.
Table 8–6 Not Visible Through the GUI

Deleted Allocations have been set to be deleted from the 7
Allocation application tables by the user selecting
the Delete button in the front end screen that
holds 'what if' summary data. The next time the
allocation deletion logic is run, the record is
removed from the tables.
Approval In Process This status is used when the system is writing an 8
approval request to the queue.
Reservation In Process This status is used when the system is writing a 9
reservation request to the queue.
Allocation Process Status

Significant functionality is attached to the status numbers in the system. The tables
below reflect the “process_status” column on the ALC_ALLOC table.
Table 8–7 Process Status Column

Not Calculated The allocation has not been calculated. 1
Calculation Waiting The allocation is waiting to be processed by the 2
algorithm. The user cannot access an allocation
with this status.
Calculating The system is in the process of calculating this 3
allocation. The user cannot access an allocation
with this status.
Calculated The allocation has been calculated successfully. 4
Calculation Error An error was encountered during calculation. 6
Size Profile Calculation The size profile was not found for all parent/diff 7
Error combinations on the allocation. Users must adjust
their size profiles and recalculate the allocation.
Ideal Weeks of Supply This error occurs if the allocation weeks of supply 8
(IWOS) Calculation Error data are not sufficient for the algorithm
requirements for calculation.

Table 8–7 (Cont.) Process Status Column

Quantity Limits Conflict This error occurs if quantity limits are defined for 9
a pack and non-sellable pack containing the same
item. The system requires the user to resolve the
conflict manually.
Status Error The system encountered an error when 10
submitting, reserving or approving this
allocation.
Status Waiting The system is in the process of submitting, 11
reserving or approving this allocation. The user
cannot enter an allocation with this status
Status Processing The system is in the process of submitting, 12
reserving or approving the allocation. The user
cannot enter an allocation with this status
Status Processed The allocation has been approved, reserved or 13
submitted successfully.
Available Inventory Error This error occurs if the inventory quantities that 14
the allocation was based upon has increased or
decreased by another part of the system since the
time of calculation. The user must recalculate and
approve based on the current inventory.
Item Source Conflict This error occurs if an allocation is created using 17
a purchase order in one allocation, and then a
user attempts to create another allocation using
an associated advance shipping notice (ASN).
Once the purchase order allocation is approved,
entering the ASN allocation prompts a question
to the user stating that he or she must delete any
associated purchase order allocations to continue
using the ASN allocation. If the user selects
‘Cancel’, the ASN allocation is set to this new
status, ‘Item Source Conflict.’ The allocation is
then ‘locked down’ until either the user deletes
the purchase order allocation or deletes the ASN
allocation.
Scheduled This scheduled allocation has been created 18
successfully.
Schedule Error This error occurs if one or more errors occur 19
when scheduled allocation was created.
Sources of Data Used by Rules to Determine Gross Need

Gross Need is the need of the rule level selected. To accurately determine individual
gross need, retailers want the flexibility to choose forecast data, plan data, receipt plan
data, sales history data, or combinations of this data.
Through the front end, retailers select a rule based on a portion of this data that
accurately gathers gross need. The source of the data used by each rule is described in
this section.
To determine the net need at the store or warehouse level, the system takes the gross
need and subtracts from it the stock-on-hand at the store or warehouse level. The
equations that Oracle Retail Allocation uses to determine the stock-on-hand at the
store or warehouse is described later in this chapter.

Note: For a description of how the following rules use the data to
determine gross need, see the Oracle Retail Allocation User Guide.
History Data Sources

For this rule, data is gathered primarily from the following tables:
Table 8–8 Data Tables (History Sources)

RMS 13.2.5 Legacy System
DEPT_SALES_HIST This table contains one row for each dept-location-week-sales
type combination. Sales history information about each
combination is held here.
CLASS_SALES_HIST This table contains one row for each class-location-week-sales
SUBCLASS_SALES_HIST This table contains one row for each
subclass-location-week-sales type combination. Sales history
information about each combination is held here.
ITEM_LOC_HIST This table contains one row for each item-location-week-sales
combination may be held here.
Forecast Data Sources

For this rule, data is gathered from the following tables:
Table 8–9 Data Table (Forecast Data Sources)

DEPT_SALES_FORECAST This table holds the forecast information summed to the
department-location-eow_date.
CLASS_SALES_FORECAST This table holds the forecast information summed to the
class-location-eow_date and should be partitioned by domain_
id, as well. Thus, if only a portion of the domains is forecasted,
then the rebuild is done by domain_id.
SUBCLASS_SALES_ This table holds the forecast information summed to the
FORECAST subclass-location-eow_date and should be partitioned by
domain, as well. Thus, if only a portion of the domains is
forecasted, then the rebuild is done by domain_id.
ITEM_FORECAST This table holds the item level forecasted information from the
RDF extractions. This table holds all item types. This table
should be partitioned according to the domain level.
Plan Data Sources

For this rule, data is gathered from the following table:
ALC_PLAN
For a more detailed description of this table, see the section, Planning Table in Oracle
Retail Allocation, in the Functional and Technical Integration chapter.
Receipt Plan Data Sources

For this rule, data is gathered from the following table:
ALC_RECEIPT_PLAN

For a more detailed description of this table, see the section, "Receipt Plan Data
Sources", in the Functional and Technical Integration chapter.
History and Plan Data Sources

For this rule, the plan portion of data is gathered from the following plan table in
Oracle Retail Allocation:
ALC_PLAN
The history portion of data is gathered from the following tables:
Table 8–10 Data Table (History and Plan Data Source)

combination is held.
combination is held.
information about each combination is held.
Plan Re-project Data Sources
Note: For a description of the Bayesian algorithm that is used in this

section, see "Allocation Calculations" in the Allocations Calculations
chapter.
For this rule, the historical and future plan data is gathered from the following table in
ALC_PLAN
The history portion of data is gathered from the following tables:
Table 8–11 Data table (History Source)

information about each combination is held here.

Corporate Rules
For this rule, data is gathered from the selected column of the following tables in
■ ALC_CORPORATE_RULE_HEAD
■ ALC_CORPORATE_RULE_DETAIL
The column selection is based on which corporate rule is picked by the user.
Note: If the retailer plans ideal weeks of supply (IWOS) by

product-location, the corporate table can be accessed to create
different ideal weeks of supply by store. If the retailer does not plan
IWOS, a field can be created that contains the same IWOS for every
store.
Quantity Limits
Quantity Limits allows the user to limit the allocation. This feature allows the user to
set parameters that affect different stages of the allocation for the product-stores or
product-warehouses where they are entered. The values for each applicable quantity
limits selection are held on the applicable column of the ALC_QUANTITY_LIMITS
table.
Using Quantity Limits, the value that gets allocated can be altered according to the
user’s preference. There are six constraints for quantity limits: Min, Max, Threshold,
Week Of Supply (WOS), Trend, and Min Need.
For example, if the user wants to allocate at least 100 units of merchandise irrespective
of the need, a minimum constraint of 100 can be applied. In this case, 100 units get
allocated (if there is enough inventory to support it). Though the quantity limit gets
accounted at the lowest level entity (that is, item/store combination), the retailer can
also supply the quantity limits values at a higher level such as group of stores or
warehouses.
Quantity Limits should work in the same manner for staple items, sellable and
non-sellable staple packs since all these types of items/packs inventory are maintained
at the same unit (item or pack) that gets allocated. For fashion items, though the
inventory is maintained at the SKU level, allocation occurs for the parent/diff.
However, you may choose to de-aggregate the parent/diff within allocation and
distribute only those sizes/components which are available to allocate. Two more
quantity limits - "Minimum Pack" and "Maximum Pack" can be applied in an
allocation using the 'Pack Distribution' mode. These can also be applied in the 'Simple'
mode but in specific cases where the allocation contains only pack items that have
been selected to be allocated as a single entity.
Net Need at Store Level Calculation

On a fundamental level, net need is gross need minus the on-hand at the store or
warehouse.
Note: Although quantity limits also affect net need, they are not
addressed in the calculation illustrated by this section.
To determine the gross need, Oracle Retail Allocation gathers the information based
upon one of the rules selected by the retailer through the front end. Oracle Retail

Allocation uses the following equation to determine the on-hand at the location that is
subtracted from the gross need result.
For a store location,
On Hand = (Stock-on-hand at the store+ Stock in transit+ Stock on order [stock that is
expected by the on order commit date]+ Transfers of stock expected + Stock on
allocation) - (Outgoing transfers + Return to vendor stock+ Unavailable stock+
Transfers on reserve) = (SOH +In Transit + On Order + TSF Expected + On Alloc) -
(TSF Out + RTV + Unavailable + TSF Reserved)
For a warehouse location, On Hand =
(Stock-on-hand at the warehouse + Stock in transit + Stock on order [stock that is
expected by the on order commit date] + Transfers of stock expected + Stock on
allocation) - (Outgoing transfers + Return to vendor stock+ Unavailable stock +
Transfers on reserve + Outbound allocations) = (SOH + In Transit + On Order + TSF
Expected + On Alloc) - (TSF Out + RTV + Unavailable + TSF Reserved + Alloc Out).
For determining the on hand quantity, we need to consider all these different
inventory buckets, some of which are present in Allocation while the rest are derived
from RMS forms/tables/views.
Allocation side
■ SOH at the store
■ Stock in transit
■ Stock on order
■ Stock On Alloc
■ Back orders
RMS side
■ TSF Expected
■ TSF Reserved
■ TSF Out
■ RTV
■ Unavailable
■ Back orders
■ Alloc Out (only for warehouses)
See the Selecting Policies section in the Creating Standard Allocations chapter of the
Oracle Retail Allocations User Guide for additional information.
Closing Allocations
This section addresses the three possible methods of closing allocations. Note that the
closure of the allocation in Oracle Retail Allocation entails 'all or nothing' processing
logic.
■ Warehouse and Store initiated Closures: The majority of RMS allocation records
should be closed as part of the retailer's warehouse management system and the
retailer's store inventory management system integration with RMS.
■ For purchase orders closed via batch functionality: RMS allocation records
attached to these closed purchase orders are closed, if the allocation meets RMS
validations. RMS cancels the associated quantities on the RMS allocation records

and closes the RMS allocation records. All the quantities remaining for related
RMS allocation records are cancelled, and the RMS allocation records are closed if
no quantities are in transit. If the RMS allocation records cannot be closed, there is
no further action.
■ For purchase orders closed manually online: If RMS allocation records exist when
the user attempts to either cancel an item or cancel all items, a message offers the
user an option to cancel the associated RMS allocation records or not. If the user
selects to close the allocations, all the quantities remaining for related RMS
allocation records are cancelled, and the RMS allocation records are closed if no
quantities are in transit. If the user selects to not close the allocations, there is no
further action.
Note: The Oracle Retail Allocation application is updated through

the table triggers when actions occur on RMS allocation records.

9
Functional and Technical Integration
9
This chapter discusses the integration among Oracle Retail Allocation and other
systems and it provides the following:
■ An integration interface allocation-related dataflow across the enterprise.
■ The tables and triggers that are in external systems or related to external systems
that Oracle Retail Allocation uses (for example, RMS).
■ A functional description of RMS dependencies and assumptions that affect Oracle
Retail Allocation.
■ Information necessary to integrate Oracle Retail Allocation and Oracle Retail
Workspace.
Integration Interface Allocation-Related Dataflow

This section provides an overview as to how Oracle Retail Allocation is functionally
integrated with other systems (including other Oracle Retail systems). The discussion
primarily concerns the flow of allocation-related business data across the enterprise.
Note: Symbol denotes tables held on the Merchandising table. Oracle

Retail allocation pulls the data from these Merchandising tables
through the use of the JDBC connection.
Functional and Technical Integration 9-1

Figure 9–1 Oracle Retail Allocation-Related Dataflow Across the Enterprise
Note: Oracle Retail allocation pulls the data from the Merchandising
tables in RMS using the JDBC connection.
The diagram above shows the overall direction of the dataflow among the products.
The accompanying explanations are written from a system-to-system perspective,
illustrating the movement of data.
From Oracle Retail Demand Forecasting System to Oracle Retail Allocation via
Merchandising System
The history data is subjected to processing that yields data that is sent back to the
merchandising system. From there, Oracle Retail Allocation pulls the following data:
■ Forecasting data: Oracle Retail Allocation accesses forecasting data that originates
in the Oracle Retail Demand Forecasting (RDF) system. RDF is Oracle Retail's
statistical and causal forecasting solution. It uses state-of-the-art modeling
techniques to produce high quality forecasts with minimal human intervention.
RDF is an application that resides on the Oracle Retail Predictive Application
Server (RPAS). Oracle Retail Allocation uses forecasting data as a basis for
calculating gross need and can access the following five levels of forecasting data:
department, class, subclass, style-color and item.
■ Store grade group data: Oracle Retail Allocation accesses store grade group data
that originates in Grade. Grade is Oracle Retail's application that groups store
locations together intelligently, based on similarities in performance, customer
type, geography, or some other factor that allows the stores within each group to

be treated as one unit. Grade is an application that is part of the Oracle Retail
Predictive Application Server (RPAS). Internally, Oracle Retail Allocation also
updates its store grade groups data groups based on the most current definitions.
This update plays an important role when many months pass between initial and
final allocations.
From Oracle Retail Planning Application to Oracle Retail Allocation
Plan Data
Oracle Retail Allocation accesses plan data that originates in the planning application
(including Oracle Retail's planning applications that reside on the RPAS server). The
RPAS products are applications that provide functionality for developing, reconciling,
and approving plans. When interfacing with Oracle Retail planning applications,
Oracle Retail Allocation accesses department, class, subclass, parent/diff, or SKU plan
data at the store-week level. Oracle Retail Allocation can be used as a tool to verify the
final product-store plans and to initiate a PO to execute the plan. In other words,
Oracle Retail Allocation can take the retailer's plan or forecast and execute it. Both the
Oracle Retail and the legacy planning applications populate a planning table, ALC_
PLAN, which resides within Oracle Retail Allocation. See the section, "Planning Table
in Oracle Retail Allocation," later in this chapter.
Note:
■ Oracle Retail Allocation interfaces with Oracle Retail Assortment
Planning by way of an output file from Assortment Planning
through Oracle Retail Extract, Transform, and Load (RETL) to
access only SKU, style-color data at the store-week level. For more
information, see the chapter, "Oracle Retail Extract, Transform,
and Load (RETL) Batch Processing".
■ RMS is the system of record for Oracle Retail Allocation. Hence
Allocation inherits the merchandise hierarchy from RMS. RMS
and Assortment Planning (AP) have different merchandise
hierarchies. Users of RMS/AP/Allocation who wish to export
information from AP to Allocation must ensure that the AP
merchandise hierarchy is compatible with that of
RMS/Allocation.
From Size Profile Optimization to Oracle Retail Allocation
Size Profile Data

Oracle Retail Allocation uses size profile data from Oracle Retail Size Profile
Optimization (SPO) system. SPO creates optimal profiles of size distribution by both
merchandise category and by store. The size profile data is extracted at the following
levels: department level, class level, sub-class level and item level. The data for all the
levels are extracted in a single file. For more information, see the section, Size Profile
Logic in the Allocation Calculations chapter, and see the Oracle Retail Extract,
Transform, and Load (RETL) Batch Processing chapter.

From Retail Demand Forecasting/Curve to Oracle Retail Allocation
Size Profile Data

Curve data becomes size profile data once it's integrated into Retail Allocation. If
allocations are made at the style level, Retail Allocation utilizes the Curve data to get
to the SKU level. For more information, see the section, Size Profile Logic in the
Allocation Calculations chapter, and see the Oracle Retail Extract, Transform, and
Load (RETL) Batch Processing chapter.
From Oracle Retail Warehouse Management System to Oracle Retail Allocation via
Oracle Retail Merchandising System
■ Appointment data
Appointment data is one source that identifies item(s) to be allocated.
■ Warehouse inventory position data
■ ASN, BOL, and Transfer information
From Oracle Retail Promotion Management to Oracle Retail Allocation

RPM provides the following to Allocation:
■ Future Retail Price Data - Oracle Retail Allocation has the ability to get a real time
price from RPM as it is integrated directly with RPM. Allocation uses this data to
provide you with the future retail price value of the entire allocation (based on its
quantities). In addition, you can access future retail price values by location and by
item.
From Oracle Retail Merchandising System to Oracle Retail Allocation
Note for RMS users only: Item, purchase order, supplier, sales and
other data are accessed directly from the RMS tables, with no need to
interface data via batch modules.
■ Item data Oracle Retail Allocation can allocate at the item, style-color, pack, or
item list level. Styles, items, and packs can be mixed on a single allocation.
■ PO data
■ Hierarchy data
■ Sales history data (for items, user-defined attributes (UDA), warehouses, stores,
and so on)
■ Foundation data (supplier data, shipping tables, and so on)
From Oracle Retail Allocation to Oracle Retail Merchandising System

Oracle Retail Allocation calculates the allocation based on the information it has
received from the merchandising system. Once the retailer reviews and approves the
allocation, Oracle Retail Allocation sends the following information back to the
merchandising system:
■ Approved or reserved allocation data

Persistence Layer Integration
■ Worksheet status POs that contain product, supplier and quantity information (the
only remaining actions to be taken in the merchandising system are to approve the
PO and, if desired, to truck scale the PO.) These worksheet status purchase orders
may be created or updated from within the Oracle Retail Allocation front end.
From Oracle Retail Merchandising System to Oracle Retail Warehouse Management

System
Note for RMS users only: Oracle Retail Allocation utilizes the
existing integration between RMS and RWMS. This interface currently
passes purchase order, item, location, and allocation information from
RMS to RWMS.
Based upon the approved allocation information from Oracle Retail Allocation, the
merchandising system sends the following information to the distribution
management system:
■ Approved allocation data represents the store quantity instructions for allocating a
specific quantity of stock at the store level.
From Oracle Retail Active Retail Intelligence to Oracle Retail Allocation

Oracle Retail Active Retail Intelligence (ARI) is an exception management and
resolution system driven by custom business rules. Depending upon ARI's
configuration, an ARI user could receive an alert that includes a link to Oracle Retail
Allocation in the form of a URL address. The user could then log on to Oracle Retail
Allocation in order to address the contents of the ARI alert.

This section addresses Oracle Retail Allocation's persistence layer method of
integration:
Persistence Layer Integration (Including Tables and Triggers)
Tables Populated by External Systems

The following tables are owned by Oracle Retail Allocation. The data within them is
populated by external systems. For descriptions of each table and its columns, see the
Oracle Retail Allocation Data Model.
■ ALC_CORPORATE_RULE_DETAIL
■ ALC_CORPORATE_RULE_HEAD
■ ALC_IDEAL_WEEKS_OF_SUPPLY
■ ALC_PLAN
■ ALC_RECEIPT_PLAN
■ ALC_SIZE_PROFILE
– Can also be populated through size profile setup via the front end of the
application.

Planning Table in Oracle Retail Allocation

Planning applications populate a planning table, ALC_PLAN, that resides within
Oracle Retail Allocation. This table includes the following columns:
■ Plan ID
■ Loc
■ EOW.date
■ Department
■ Class
■ Subclass
■ Item
■ Diff1_id, Diff2_id, Diff3_id, Diff4_id
■ Quantity
A record can thus exist at any of the following levels by week-store-quantity:
■ Department
■ Department-class
■ Department-class-subclass
■ Item-color
■ Item
The ALC_RECEIPT_PLAN table includes the following columns:
■ Plan ID
■ Loc
■ EOW.date
■ Department
■ Class
■ Subclass
■ Item
■ Diff1_id, Diff2_id, Diff3_id, Diff4_id
■ Quantity
A record can thus exist at any of the following levels by week-store-quantity:
■ Department
■ Department-class
■ Department-class-subclass
■ Item-color
■ Item
■ Pack
Merchandising Interface Tables

Oracle Retail Allocation and RMS share certain database tables and processing logic.
This integration provides the following two important benefits:

■ The number of interface points that need to be maintained is minimized.

■ The amount of redundant data (required if the rest of the Oracle Retail product
suite is installed) is limited.
Oracle Retail Allocation exchanges data and processing with RMS in four ways:
■ By reading directly from RMS tables.
■ By directly calling RMS packages.
■ By reading Oracle Retail Allocation views based on RMS tables.
■ Oracle Retail Allocation triggers reside in RMS tables. These triggers cause actions
(create, delete, update) on RMS tables based on Oracle Retail Allocation business
rules.
Oracle Retail Merchandising System Tables (for Retailers with Oracle Retail
Merchandising System only) used by Oracle Retail Allocation
The following table illustrates the tables from which Oracle Retail Allocation gets its
data from RMS.
Table 9–1 RMS Tables Used by Allocation

RMS Tables
Functional Area Associated Tables
Item data SUB_ITEMS_HEAD
SUB_ITEMS_DETAIL
ITEM_MASTER
ITEM_SUPP_COUNTRY
ITEM_SUPPLIER
ITEM_LOC
ITEM_LOC_HIST
ITEM_LOC_SOH
ITEM_PARENT_LOC_HIST
Skulist data SKULIST_HEAD
SKULIST_DETAIL
Pack data PACKITEM
ITEM_MASTER
ITEM_LOC
Order data ORDHEAD
ORDLOC_WKSHT
ORDLOC
ORDSKU
ALLOC_HEADER
ALLOC_DETAIL
SHIPMENT

Table 9–1 (Cont.) RMS Tables Used by Allocation

RMS Tables
Supplier data SUPS
ITEM_SUPPLIER
Location list data LOC_LIST_HEAD
LOC_LIST_DETAIL
LOC_LIST_CRITERIA
Merchandise hierarchy data DEPS
CLASS
SUBCLASS
ITEM_PARENT
DIFF
SKU
Organizational hierarchy STORE
data
WH
WH_STORE_ASSIGN
Shipment data SHIPMENT
SHIPSKU
Store grade data STORE_GRADE_GROUP
STORE_GRADE
STORE
BUYER
STORE_GRADE_STORE
Location traits data LOC_TRAITS
LOC_TRAITS_MATRIX
LOC_AREA_TRAITS
LOC_REGION_TRAITS
LOC_DISTRICT_TRAITS
Transfer data TSFHEAD
TSFDETAIL
User defined attribute UDA
(UDA) data
UDA_VALUES
UDA_ITEM_LOV
Forecast data DEPT_SALES_FORECAST
CLASS_SALES_FORECAST
SUBCLASS_SALES_FORECAST
ITEM_FORECAST

Table 9–1 (Cont.) RMS Tables Used by Allocation

RMS Tables
Sales data DEPT_SALES_HIST
CLASS_SALES_HIST
SUBCLASS_SALES_HIST
ITEM_LOC_HIST
ITEM_PARENT_LOC_HIST
Appointment data APPT_HEAD
APPT_DETAIL
Auto Quantity Limits DEP
CLASS
SUBCLASSS
ITEM_PARENT
DIFF
SKU
GROUP_TYPE
GROUP_VALUE
MINIMUM_NET_NEED
MAXIMUM_NET_NEED
THRESHOLD
TREND
WEEKS_OF_SUPPLY
MINIMUM_GROSS_NEED
MINIMUM_PACK
MAXIMUM_PACK
START_DATE
END_DATE
Oracle Retail Allocation-Owned Triggers Residing on Oracle Retail

Merchandising System Tables
Table 9–2 Triggers

Triggers Details
ALC_TABLE_ALD_AUR - 1 This trigger is involved in the following processing: Whenever a
-4 portion of an allocation order is worked on by the distribution
center by selecting, distributing, transferring or receiving
inventory, the allocation within Oracle Retail Allocation is
placed into a 'Processed' status. The user can no longer change
that allocation in Oracle Retail Allocation.
ALLOC_STATUS_TRIGGER This trigger is on the RMS table ALLOC_HEADER. The trigger
updates the status in Oracle Retail Allocation table ALC_ALLOC
to 4 (closed). This trigger is fired only if the status on RMS table
ALLOC_HEADER is updated to 'C' (closed).

Oracle Retail Merchandising System Functional Dependencies and Assumptions
Table 9–2 (Cont.) Triggers

Triggers Details
ALLOC_STATUS_ The closure logic within the Oracle Retail Allocation application
TRIGGER_AU accounts for the multiplicity between ALLOC_HEADER records
and the Oracle Retail Allocation (ALC_XXX) tables. The table
triggers only set a Oracle Retail Allocation allocation number to
closed if all ALLOC_HEADER records have been closed.
Oracle Retail Merchandising System Functional Dependencies and

Assumptions
This section describes the functional dependencies of Oracle Retail Allocation on RMS.
Oracle Retail Merchandising System Differentiator Setup

The RMS item structure allows multiple item levels and multiple differentiators. To
structure item setup for use with Oracle Retail Allocation, the retailer must understand
the implications of the Item Aggregate Indicator and the Aggregate Indicators that
exist at the differentiator level.
The following section describes how an item family must be structured to enable the
Oracle Retail Allocation product to differentiate the items among fashion, staple and
pack items.
Fashion Item
Note: In the Allocation application and this document, the terms

'style/color' and 'parent/diff' are used interchangeably.
RMS allows for the potential of three item levels. For a customer who allocates based
on the concept of parent/diff, the style can be translated to RMS item setup as being
the level one item in the item family. The SKU can be translated to RMS item setup as
being the transaction level item (this could be level one, two or three). There is no
requirement within RMS that forces a 'fashion' item to be multi-level.
An item is viewed as a fashion item only if the Item Aggregate Indicator in the
Attributes section of the Item Master Window is selected for the style (level one item)
in the item family.
Once the item aggregate indicator has been selected, the user needs to indicate which
differentiator should be curved by allocations. Each item may contain up to four
differentiators.
The Aggregate check box is enabled when more than one differentiator is being
created for an item where the Item Aggregate Indicator has been selected. The
differentiator that the customer wants to be curved by Oracle Retail Allocation must be
the only differentiator that is not indicated on the Item Master Window.
Below is an example of a fashion item, its indicators within RMS, and what is visible.
Item 100011006 has three differentiators associated.
■ Color/pattern/width

Figure 9–2 RMS Differentiator Setup
The retailer wants to have Oracle Retail Allocation apply the curve to Color. Therefore,
it sees information within the Oracle Retail Allocation screens based upon the pattern
and width differentiators.
All of the transaction level children have their item and differentiator aggregate
indicators set to 'N'. These values are only maintained for the level one item. All other
items in the system (including packs) have those indicators defaulted to 'N'.
In this scenario, if the retailer is creating an allocation for the parent item (100011006),
it has visibility to four different levels of the 'style'.
■ 100011006 - 100% Cotton Sheets Plaid:N
■ 100011006 - 100% Cotton Sheets Plaid:S
■ 100011006 - 100% Cotton Sheets Leopard:N
■ 100011006 - 100% Cotton Sheets Leopard:S
Staple Item
A staple item is every item in the system where the level one item in the item family
does not have the Item Aggregate Indicator selected. In this scenario, the Oracle Retail
Allocation retailer has visibility to the transaction level item only. There is no roll up of
item information. The retailer also has visibility to the non-sellable packs that contain

the component staple item and is able to include or exclude those packs from the
allocation.
Pack Item
There are multiple types of packs that may be set up within RMS. The key criteria for
Oracle Retail Allocation is whether the pack is sellable or non-sellable, whether the
pack contains multiple component items and whether or not those multiple
components items are of one type (for example, fashion as opposed to staple).
When creating your packs, consider the following pack assumptions made by Oracle
Retail Allocation:
■ Oracle Retail Allocation does not have the ability to allocate packs that contain
fashion and staple items.
Summary of Items and How Oracle Retail Allocation Handles Them

■ Single staple item:
These items are individually allocated and can be selected from item LOV search
criteria.
■ Single fashion item:
These items are allocated as part of their style/color. They may also be
individually selected from the worksheet to distribute only those
sizes/components that are available to allocate. Single fashion items may also
optionally be included in a Fashion Group Allocation.
Note: Fashion packs cannot be de-aggregated.
■ Style/color:
The transaction level (item) is allocated as visible in the View Assortment window.
However, the allocation is created at the item level one/differentiator (style/color)
level. The item level one/differentiator (style/color) level is where retailers work
with the allocation.
■ Simple sellable staple pack and complex sellable staple pack:
These types of packs are included in an allocation when they are individually
allocated.
■ Simple non-sellable staple pack and complex non-sellable staple pack:
These types of packs are included in an allocation when the component of the
pack item is allocated or when the non-sellable pack itself is allocated.
■ Simple sellable fashion packs and complex sellable fashion packs:
These types of packs are included in an allocation when they are individually
allocated. They are not being automatically included in any fashion items
allocation.
■ Simple non-sellable fashion packs and single color complex non-sellable
fashion packs:
These packs can be allocated as part of a style/color or they may also be allocated
individually (components must stay within the pack). They could also be allocated
as part of a Fashion Group allocation.

■ Multi-color complex non-sellable fashion packs:

These packs can be allocated individually or they can be allocated as part of a
Fashion Group Allocation.
Oracle Retail Allocation Functional Assumptions Related to Oracle Retail

Merchandising System
■ When fashion items are individually selected for an allocation (rather the selecting
a style/color), the items are allocated as staple items.
■ A single allocation cannot have both fashion item(s) and staple item(s).
■ Non-sellable fashion packs are visible on the trans level view of the Assortment
View screen.
■ The list of values on the search screen displays staple items, sellable/non-sellable
staple packs, and sellable simple/complex fashion packs.
■ The stop shipment record for a non-sellable staple pack must be at the component
item level for the stop shipment to be recognized by Oracle Retail Allocation. A
record for the non-sellable staple pack itself has no effect.


10
01 Oracle Retail Extract, Transform, and Load
(RETL) Batch Processing
The module works in conjunction with the Oracle Retail Extract Transform and Load
(RETL) framework. This architecture optimizes a high performance data processing
tool that allows database batch processes to take advantage of parallel processing
capabilities.
The RETL framework runs and parses through the valid operators composed in XML
scripts.
This chapter provides an overview of Oracle Retail Allocation RETL processing and
defines the export file from Curve/Plan to Oracle Retail Allocation that is used when
exporting Curve/Financial Plan values. For more information on RETL, see the
product’s Programmer's Guide.
Note: In this chapter, some examples refer to RETL programs that

are not related to Oracle Retail Allocation. References to these
programs are included for illustration purposes only.
Note: The RETL loads into Allocation are point to point integration
between Oracle Retail product, and are not designed to support
generic uploads from other systems.
Functional Overview
The extracts from RETL may contain up to four levels of plan/profile. They consist of
the department level, class level, subclass level and item level. All of these levels are
contained in a single normalized file. Each record in the Curve file has a dedicated
'space' and distinct position for department, class, subclass, item, store, diff1, diff2,
diff3, diff4 and size profile quantity values and each record in the Plan file has a
dedicated 'space' and distinct position for department, class, subclass, item, store,
diff1, diff2, diff3, diff4, EOW date and plan quantity values. It is crucial that the
records are mapped using the correct positions and space/padding rules for each data
value.
■ Regardless of the level of financial plan/profile, each record must include a store,
diff value in one of the four diff value fields and a quantity value (including an
EOW date for Plan only).
Oracle Retail Extract, Transform, and Load (RETL) Batch Processing 10-1
Oracle Retail Extract, Transform, and Load Batch Processing Architecture
■ Department-level financial plan or profiles include a department data value in the

dedicated department field. The class, subclass and item fields do not contain any
values. They remain empty.
■ Class-level financial plan or profiles include a department and class data value in
the dedicated department and class fields. The subclass and item fields do not
contain any values. They remain empty.
■ Subclass-level financial plan or profiles include a department, class and subclass
data value in the dedicated department, class and subclass fields. The item fields
do not contain any values. They remain empty.
■ All of the department, class and subclass record exports contain only the
non-aggregate diff values mapped from the specific diff value in ITEM_MASTER
to the corresponding diff value in the export file. It is crucial that the
non-aggregate diffs are mapped to the correct diff_id in the export file.
■ Item-level profiles include aggregate level IDs in the dedicated item field. The
department, class and subclass fields do not contain any values. They remain
empty. The item level export records contains both the aggregate and
non-aggregate diff values mapped from the specific diff id in ITEM_MASTER to
the associated diff position in the export file.
■ Item-Level financial plan or profiles include item data value in the dedicated item
field. The department, class and subclass fields do not contain any values. They
remain empty.
■ All the data values must start in the beginning of the corresponding field, and
padding comes after the data to fill all the dedicated space for that data field.

The diagram below illustrates the extraction processing architecture. The plan/size
profile architecture adheres to what is shown in the diagram:
The architecture relies upon two distinct stages, each of which is described in the
passages that follow.
Figure 10–1 RETL Batch Processing Architecture
Processing Stage 1
Stage 1 involves importing plan/profile data and looking up required information in
the RMS ITEM_MASTER table (item-level plans/profiles only). The resulting output
from this stage is a temporary table that contains any item-level and
department/class/subclass-level plans/profiles.
The detailed flow is as follows:

1. Insert dept-level plans/profiles directly into the staging table.

2. Insert class-level plans/profiles directly into the staging table.
3. Insert subclass-level plans/profiles directly into the staging table.
4. The item-level plans/profiles require lookups with the ITEM_MASTER table. The
processing logic for transaction-level items is to do a three-way left outerjoin on
the ITEM_MASTER table to retrieve each parent and grandparent item aggregate
indicators. The Item file then lookups its item id in the item master table and uses
the STYLE set as the parent or grandparent item id whose ITEM_AGGREGATE_
IND = 'Y'. These item level plans/profiles are then inserted into the staging table.
Error Handling
Any item records that do not have a parent and grandparent are flagged as warnings.
Any items in the incoming data file that do not match an item in the ITEM_MASTER
table are flagged as errors.
Processing Stage 2
Stage 2 involves inserting and updating the plan or profile records into the final
destination ALC_PLAN, ALC_RECEIPT_PLAN, or ALC_SIZE_PROFILE table
respectively.
The detailed processing is as follows:
1. Update quantity when matched department, class, subclass, style, store, size1,
size2, size3, size4.
2. Otherwise, insert record.
Configuration
This section covers configuration.
Oracle Retail Extract, Transform, and Load

Before trying to configure and run Oracle Retail Allocation RETL, install RETL version
13.2, which is required to run Oracle Retail Allocation RETL. Run the 'verify_retl'
script (included as part of the RETL installation) to ensure that RETL is working
properly before proceeding.
Oracle Retail Extract, Transform, and Load User and Permissions

Oracle Retail Allocation RETL should be installed and run as the RETL user.
Additionally, the permissions should be set up as per the RETL Programmer's Guide.
Oracle Retail Allocation RETL reads, creates, deletes and updates data for tables. If
these permissions are not set up properly, processing fails.
Environment Variables
See the RETL Programmer's Guide for RETL environment variables that must be set up
for your version of RETL. You need to set ALCHOME to your base directory for Oracle
Retail Allocation RETL. This is the top level directory that you selected during the
installation process (see Oracle Retail Allocation Installation Guide) in your .kshrc, you
should add a line such as the following:
export ALCHOME=<base directory path for ALLOCATION RETL>
Execute the setup-security-credential.sh script after the installation from RFX_

HOME/bin directory. This script provides the options for adding/updating the
database credentials. Enter the values for the following parameters:
■ dbuseralias
■ username
A secure wallet file (cwallet.sso) is created under "RFX_HOME/etc/security" directory
of RETL installation.
alc_config.env Settings
On the Oracle Retail Allocation side, make sure to review the environmental
parameters in the alc_config.env file before executing the batch module. Depending
upon your local settings, the variables may need to be changed.
Configure Oracle Retail Extract, Transform and Load

1. Log in to the UNIX server with a UNIX account that runs the RETL scripts.
2. Change directory to $ALCHOME/rfx/etc.
3. Modify the alc_config.env script:
■ Change the DBNAME variable to the name of the Oracle Retail Allocation
database. For example:
export DBNAME=int9i
■ Set the user alias fields such as RETL_WALLET_ALIAS and ORACLE_

WALLET_ALIAS.
■ Set the other variables namely: RFX_HOME, RFX_TMP, TNS_ADMIN,
ALCHOME, ORACLE_HOME, JAVA_HOME, PATH, LD_LIBRARY_PATH,
SPO_GID_FILENAME.
Update the rfx.conf, vdate.txt files with the DB information and other local settings
necessary.
Running the Module

This section covers running the module.
Schema File
RETL uses a schema file to specify the format of an incoming or outgoing dataset. The
schema file defines each column's data type and format, which is then used within
RETL to format/handle the data. Schema file names are hard-coded within each
module because they do not change on a day-to-day basis. All schema files end with
'.schema' and are placed in the 'rfx/schema' directory. For more information about
schema files, see the latest RETL Programmer's Guide.
The input data schema file for the Oracle Retail Allocation module is named as alcl_
plan.schema for Plan and as alcl_size_profile.schema for profile and is shown later in
this chapter.
Mandatory Multi-Threading and Command Line Parameters

In contrast to the way in which multi-threading is defined in UNIX, Oracle Retail
Allocation uses 'multi-threading' to refer to the running of a single RETL program

multiple times on separate groups of data simultaneously. Multi-threading can reduce

the total amount of processing time.
For this Oracle Retail Allocation module, multi-threading is mandatory, and the
file-based module has to be run once for each input file.
■ The alcl_pan / alcl_size_profile module requires the following two input
parameters:
■ The uniquely named thread number. Note that the thread number is used
internally and is not related to any output file or table name.
■ The following example illustrates a scenario in which the retailer runs the alcl_
size_profile.ksh module three times for three input files:
The load batches, example alcl_size_profile.ksh, loads its data from $ALC_
HOME/data
alcl_size_profile.ksh profile_01.dat 1
alcl_size_profile.ksh profile_03.dat 3
The transform batches alct_plan and alct_size_profile do not take any input
parameters. They execute the flat files in the path $ALC_HOME/data alcl_size_
profile.ksh profile_02.dat 2. Running only alct_size_profile.ksh at the prompt
executes the transform scripts.
Program Features
The extraction programs are written in the RETL framework and include the following
features:
■ Business virtual date
■ Program return code
■ Program status control files
■ Restart and recovery
■ Message logging
■ Program error file
■ Reject files
Business Virtual Date

The business virtual date must be placed in the vdate.txt file in the
$ALCHOME/rfx/etc directory prior to running the RETL module.
Program Return Code

RETL programs use one return code to indicate successful completion. If the program
successfully runs, a zero (0) is returned. If the program fails, a non-zero is returned.
Program Status Control Files

To prevent a program from running while the same program is already running
against the same set of data, the Oracle Retail Allocation RETL code utilizes a program
status control file. At the beginning of each module, alc_config.env is run. It checks for
the existence of the program status control file. If the file exists, then a message stating,
'${PROGRAM_NAME} has already started', is logged and the module exits. If the file
does not exist, a program status control file is created and the module executes.
If the module fails at any point, the program status control file is not removed, and the
user is responsible for removing the control file before re-running the module.
File Naming Conventions

The naming convention of the program status control file allows a program whose
input is a text file to be run multiple times at the same time against different files.
The name and directory of the program status control file is set in the configuration file
(alc_config.env). The directory defaults to $ALCHOME/error. The naming convention
for the program status control file itself defaults to the following dot separated file
name:
■ The program name
■ The input filename
■ 'status'
■ The business virtual date for which the module was run
For example, the program status control file for the alcl_size_profile.ksh program
(with an input file name of alcl_size_profile_01.dat specified as the first argument on
the command line) would be named as follows for the batch run of January 5, 2001:
$ALCHOME/error/alcl_size_profile.alcl_size_profile_01.dat.status.20010105
Oracle Retail Allocation Oracle Retail Extract, Transform, and Load Restart and
Recovery
The Oracle Retail Allocation RETL module imports data from a flat file, performs
transformations if necessary and then loads the data into the applicable Oracle Retail
Allocation table.
This module uses a single RETL flow and does not require the use of restart and
recovery. If the extraction process fails for any reason, the problem can be fixed, and
the entire process can be run from the beginning without the loss of data. For a module
that takes a text file as its input, the following two choices are available that enable the
module to be re-run from the beginning:
1. Re-run the module with the entire input file.
2. Re-run the module with only the records that were not processed successfully the
first time.
Message Logging
Message logs are written while the module is running in a format described in this
section.
Daily Log File

Every RETL program writes a message to the daily log file when it starts, while it is
running, and when it finishes. The name and directory of the daily log file is set in the
configuration file (alc_config.env). The directory defaults to $ALCHOME/log. All log
files are encoded UTF-8.
The naming convention of the daily log file defaults to the following 'dot' separated
file name:
■ The business virtual date for which the module is run.
■ '.log'

For example, the location and the name of the log file for the business virtual date of
January 5, 2001 would be the following:
$ALCHOME/log/20010105.log
Format
As the following examples illustrate, every message written to a log file has the name
of the program, a timestamp, and either an informational or error message:
alct_size_profile 16:06:30: Program started.Number of input files processed = 1.
Number of output files produced = 1
alcl_size_profile 13:20:01: Program started for thread 1…
alcl_size_profile 13:20:05: Analyzing temp table rmsint1201.alcl_size_profile_
temp_1
alcl_size_profile 13:20:13: Merging into alc_size_profile
alcl_size_profile 13:20:27: Program completed successfully for thread 1.
alct_size_profile 16:06:30: Program completed without errors
If a program finishes unsuccessfully, an error file is usually written that indicates

where the problem occurred in the process. There are some error messages written to
the log file, such as 'No output file specified', that require no further explanation
written to the error file.
Program Error File

In addition to the daily log file, each program also writes its own detail flow and error
messages. Rather than clutter the daily log file with these messages, each program
writes out its errors to a separate error file unique to each execution.
The name and directory of the program error file is set in the configuration file (alc_
config.env). The directory defaults to $ALCHOME/error. All errors and all routine
processing messages for a given program and input file on a given day go into this
error file (for example, it contains both the stderr and stdout from the call to RETL).
All error files are encoded UTF-8.
The naming convention for the program's error file defaults to the following 'dot'
separated file name:
■ The program name
■ The business virtual date for which the module was run
For example, all errors and detail log information for the alcl_size_profile program
would be placed in the following file for the batch run of January 5, 2001:
$ALCHOME/error/alcl_size_profile.alcl_size_profile_01.dat.20010105
The error file for the transform batch contains the name of the files processed with exit
status of each file. If any of the file has bad record like width of some field exceeding
the maximum allowed, this error file shows the bad records also.
The naming convention for the error file of the transform batch is
Program name_err.business virtual date for which the scripts were run.
For example,
alct_size_profile_err.20061005
Oracle Retail Allocation Reject Files

The Oracle Retail Allocation module may produce a reject file if it encounters data
related problems, such as the inability to find data on required lookup tables. A given
module tries to process all data and then indicates that records were rejected. All data
problems are thus identified in one pass and corrected. The module can then be re-run
to successful completion. If a module does reject records, the reject file is not removed.
The user is responsible for removing the reject file before re-running the module.
Typical Run and Debugging Situations

The following examples illustrate typical run and debugging situations for each type
of program. The file names referenced in the example below (log, error, and so on)
assume that the module is run on the business virtual date of March 9, 2001.
Example for running Transform batch
Run alct_size_profile.ksh
1. Change the directory to $ALC_HOME/src

2. In the prompt enter,
$alct_size_profile.ksh
If the module runs successfully, the following results,
alct_size_profile.ksh: 16:37:45 Data transform (awk) starting. Input file:
/home/pachaia/RPAS12_Agal/data/d1clss.01
alct_size_profile.ksh: 16:37:45 Transform completed. File: d1clss.01
d1clss.01 processing completed. Exit status: 0
/home/pachaia/RPAS12_Agal/data/d1itpt.01
alct_size_profile.ksh: 16:37:45 Transform completed. File: d1itpt.01
d1itpt.01 processing completed. Exit status: 0
alct_size_profile completed with 1 ERRORS: Thu Oct 5 16:37:45 CDT 2006
If the module does not run successfully, the following results,
****** STARTING alct_size_profile: Thu Oct 5 16:37:45 CDT 2006 ******

****** STARTING alct_size_profile: Thu Oct 5 16:37:45 CDT 2006 ******
alct_size_profile.ksh: 16:37:45 Transform completed. File: d1clss.01
d1clss.01 processing completed. Exit status: 0
/home/pachaia/RPAS12_Agal/data/d1dept.01
ERROR - too many DIFF IDs in current record of Diff Profile File.

/home/pachaia/RPAS12_Agal/data/d1clss.01
Diff Profile file name: d1dept.01
Number of Diffs found: 5
Maximum number allowed: 4
DIFF ID string: < _hh1dif_jh2dif_kh3dif_lh4dif _mh5dif 000000006>
Bad Record:
Record number 2
1414 1000000001 _hh1dif_jh2dif_kh3dif_lh4dif_
mh5dif 000000006000
alct_size_profile.ksh: 16:37:45 Transform completed. File: d1dept.01
d1dept.01 processing completed. Exit status: 2
/home/pachaia/RPAS12_Agal/data/d1itpt.01
alct_size_profile.ksh: 16:37:45 Transform completed. File: d1itpt.01
d1itpt.01 processing completed. Exit status: 0
alct_size_profile completed with 1 ERRORS: Thu Oct 5 16:37:45 CDT 2006

Example for Running Load Batch
Run alcl_size_profile.ksh:
1. Change directory to $ALCHOME/rfx/src.
2. At a UNIX prompt, enter:

alcl_size_profile.ksh <input datafile 1> <thread #>
...
If the module runs successfully, the following results:

■ Log file: Today's log file, 20010309.log, contains the messages described above in
the 'Format' passage of the 'Daily log file' section.
■ Data: The ALC_SIZE_PROFILE table exists in the Oracle Retail Allocation
database and contains the extract records.
■ Error File: The program's error file, alcl_size_profile.20010309, contains the
standard RETL flow (ending with "All threads complete" and "Flow ran
successfully") and no error messages.
■ Program status control: The program status control file, alcl_size_
profile.status.20010309, does not exist.
■ Reject File: No reject files exist.
If the module does not run successfully, the following results:
■ Log file: Today's log file, 20010309.log, may not contain the "Program completed
successfully…" message.
■ Data: The ALC_SIZE_PROFILE table exists in the Oracle Retail Allocation
database but may not contain all the records from the profile file interface.
■ Error file: The program's error file, alcl_size_profile.20010309, may contain an error
message.
■ Program status control: The program status control file, alcl_size_
profile.status.20010309, may exist.
■ Reject file: The reject file, items_not_found.dat, may exist in the $ALCHOME/data
directory.
■ Bookmark file: The bookmark file, alcl_size_profile.bkm.20010309, does not exist
because this module does not utilize restart and recovery.
Re-run the Module:

1. Determine and fix the problem causing the error.
2. Remove the program's status control file.

3. Remove the reject file (if it exists) from the $ALCHOME/data directory.
4. Change directory to $ALCHOME/rfx/src. At a UNIX prompt, enter:
% alcl_size_profile.ksh <input datafile 1> <thread #>
Oracle Retail Allocation Program Reference

This section serves as a reference to the Oracle Retail Allocation program.
By reviewing this section and the section, 'API flat file specification', the retailer should
be able to track down to the table and column level, all the extraction data that flows
into Oracle Retail Allocation.
Table 10–1 Extraction Data

Tables
Program /Files Fields Target File Target Field
Name Extracted Extracted or Table Field Field Type Length NOTES
alcl_size_ ITEM_ item alc_size_ style VAR 25
profile.ksh MASTER profile CHAR2
(25)
profile file dept dept NUMBER 4
(4)
class class NUMBER 4
(4)
subclass subclass NUMBER 4
(4)
store store NUMBER 10
(10)
size1 size1 VAR 10
CHAR2
(10)
size2 size2 VAR 10
CHAR2
(10)
size3 size3 VAR 10
CHAR2
(10)
size4 size4 VAR 10
CHAR2
(10)
qty qty NUMBER 17
(12,4)

Table 10–1 (Cont.) Extraction Data

Tables
ALC_ ITEM_ item ALC_ style VAR 25
PLAN.KSH MASTER PLAN
CHAR2
item_ (25) Use item_
parent parent as
style if
Item_
parent_
aggregate_
ind= 'Y'
item_ Use item_
grandpare grandpare
nt nt as Style
if item_
grandpare
nt_
aggregate_
ind = 'Y'
item_
aggregate_
ind
item_
parent_
aggregate_
ind
item_
grandpare
nt_
aggregate_
ind
(4)
(4)
(4)
(10)
size1 size1 VAR 48
CHAR2
(10)
size2 size2 VAR 48
CHAR2
(10)
size3 size3 VAR 48
CHAR2
(10)

Tables
size4 size4 VAR 48
CHAR2
(10)
qty qty NUMBER 12
(12,4)
ALC_ ITEM_ item ALC_ style VAR 25
RECEIPT_ MASTER PLAN
CHAR2
PLAN.KSH
(25)
item_ Use item_
parent parent as
style if
Item_
parent_
aggregate_
ind= 'Y'
item_ Use item_
grand grand
parent parent as
Style if
item_
grandpare
nt_
aggregate_
ind = 'Y'
item_
aggregate_
ind
item_
parent_
aggregate_
ind
item_
grandpare
nt_
aggregate_
ind
(4)
(4)
(4)
(10)
size1 size1 VAR 48
CHAR2
(10)
size2 size2 VAR 48
CHAR2
(10)


Tables
size3 size3 VAR 48
CHAR2
(10)
size4 size4 VAR 48
CHAR2
(10)
qty qty NUMBER 12
(12,4)
Application Programming Interface (API) Specification

This section describes the API specification.
File Layout
Plan Data File Layout

Plan data is required in Allocation for allocating items to the store based on plan
requirements at the location. The data is extracted by the predictive application server
and provided to the allocation interfaces as a flat file.
This segment describes the file format that Predictive Application System provides for
uploading plan data into RMS database for Allocation.
File Name: p1prodlevel.NN
Example: p1scls.01 (subclass, domain 01)
■ 1234567890123456789012345678901234567890123456789012345678901234567890123456
7890123456789012345678901234567890123
■ 141410001000 1000000014 _CCOLOR31_SMEDIUM
■ 20051225000000137500
Table 10–2 Plan Data File Layout

Start
Field Name Position Width Format Content
Product ID 1 25 char Alpha 141410001000
Location ID 26 20 char Alpha 10000000014
Diff IDs 46 48 char Alpha _CCOLOR31_
SMEDIUM
EOW Date 94 8 char Alpha 20051225
Quantity 102 12 char Numeric 000000137500
■ The file name should start with p1 followed by four characters for product level
and the domain number. The four product level acceptable are:
– - itpt - for item
– - scls - for subclass
– - clss - for class
– - dept - for department

■ The domain ID should be numeric.
■ The Product ID, Location ID and Diff IDs fields are left justified and blank filled.
■ The number of separate Diffs in the Diff IDs field is in the range: 0-4. The first
character of each Diff is an "_" (underscore) and the second character is the Diff
Type. No underscore characters are present in the Diff ID field other than the
character that immediately precedes each separate Diff Type within the field. Each
Diff in the Diff IDs field is lesser than 12 characters in length, including the leading
underscore character and the Diff Type.
■ The EOW Date field is in the format YYYYMMDD.
■ The Quantity field is a right-justified, zero-padded numeric and the decimal point
is omitted, but the quantity has a 4-digit decimal fraction part (e.g. 13.75 would
appear in the record as 000000137500).
■ Total length of each record is 113.
■ When uploading data the system updates the quantity if the record exists for the
hierarchy/location/Diff_id/EOW data combination or it appends the record into
the tables.
Receipt Plan Data File Layout

Receipt plan data is required in Allocation for allocating items to the store based on
receipt plan requirements at the location. The data is extracted by the predictive
application server and provided to the allocation interfaces as a flat file.
This segment describes the file format that Predictive Application System provides for
uploading receipt plan data into RMS database for Allocation.
File Name: p1prodlevel.NN
Example: p1scls.01 (subclass, domain 01)
■ 1234567890123456789012345678901234567890123456789012345678901234567890123456
7890123456789012345678901234567890123
■ 141410001000 1000000014 _CCOLOR31_SMEDIUM
■ 20051225000000137500
Table 10–3 Receipt Plan Data File Layout

Start
Diff IDs 46 48 char Alpha _CCOLOR31_
SMEDIUM
EOW Date 94 8 char Alpha 20051225
Quantity 102 12 char Numeric 000000137500
■ The file name should start with p1 followed by four characters for product level
and the domain number. The four product level acceptable are:


Type. No underscore characters are present in the Diff ID field other than the
■ The EOW Date field is in the format YYYYMMDD.
the tables.
Size Curve File Layout

Allocation application allocates quantities at the style-color level for fashion
merchandise like Blue t-shirts; Dark Blue pants etc and then distributes the allocated
quantity according to the size based on the size curve for the location. The size curve
data can be inputted into the application directly using the GUI interface in the
application or through upload from data provided by the predictive application server.
This section describes in detail the file format structure for the upload.
File Name: dXprodlevel.NN
Example: File Name: d1scls.01 (diff 1, subclass, domain 01)
Record:
■ 1234567890123456789012345678901234567890123456789012345678901234567890123456
78901234567890123456789012345
■ 100045078 1000000002 CCOLOR01_S30x32 000000137500
Table 10–4 Size Curve File Layout

Start
Diff IDs 46 48 char Alpha _
CCOLOR01_
S30x32
Quantity 94 12 char Numeric
000000137500
■ The file name should start with letter d, X is diff number being sent followed by
four characters for product level and the domain number. The four product level
acceptable are:
Type. No underscore characters is present in the Diff ID field other than the
the tables.
Schema file (alcl_size_profile.schema)

This section describes the RETL schema file (alcl_size_profile.schema) used in the
RETL script that loads the Curve export file into Oracle Retail.
Allocation's ALC_SIZE_PROFILE table:
<RECORD type="fixed" len="115" final_delimiter="0x0A">
 <FIELD name="CLASS" len="4" datatype="string"
nullable="true" nullvalue=""/>
 <FIELD name="SUBCLASS" len="4" datatype="string"
 <FIELD name="ITEM" len="25" datatype="string"
 <FIELD name="STORE" len="20" datatype="string"
nullable="false"/>
 <FIELD name="DIFF_TYPE_1" len="1" datatype="string"
nullable="false" nullvalue=""/>
 <FIELD name="DIFF1" len="10" datatype="string"
nullable="false" nullvalue=""/>

 <FIELD name="QTY" len="14" datatype="dfloat"
nullable="false"/>

</RECORD>
 <FIELD name="DEPT" len="4" datatype="string" nullable="true"
nullvalue=""/>
Schema file (alcl_plan.schema)

This section describes the RETL schema file (alcl_plan.schema) used in the RETL script
that loads the plan export file into Oracle Retail.
Allocation's ALC_PLAN table.
 <FIELD name="ITEM_ID" len="25" datatype="string"
nullable="false"/>
 <FIELD name="DIFF1_ID" len="10" datatype="string"
 <FIELD name="EOW_DATE" len="8" datatype="date"
nullable="false"/>
nullable="false"/>

</RECORD>
nullvalue=""/>
Schema File (alcl_receipt_plan.schema)

This section describes the RETL schema file (alcl_receipt_plan.schema) used in the
RETL script that loads the receipt plan export file into Oracle Retail.
Allocation's ALC_RECEIPT_PLAN table:
 <FIELD name="ITEM_ID" len="25" datatype="string"
nullable="false"/>
 <FIELD name="EOW_DATE" len="8" datatype="date"
nullable="false"/>
nullable="false"/>

</RECORD>
nullvalue=""/>
Oracle Retail Extract, Transform, and Load for Receipt and Plan
RETL scripts are required to support receipt plan logic (what the store is expected to
own) at the store/week level. This rule provides fashion retailers the option to choose
different plans coming from different source data feeds.
Large size fashion retailers can use Assortment Planning data as the pre-season source
to determine store or warehouse needs for seasonal items. The data file sent from the
Assortment Planning system is used to generate the gross need in the Allocation
system in order to create pre-allocations.
Once the selling season begins, retailers have the option to switch to a different rule
such as Plan, Forecast or Historical data to generate store demand.
Script Names
■ alct_receipt_plan.ksh
■ alct_receipl_plan.ksh
Table Name
■ alc_receipt_plan
Oracle Retail Extract, Transform, and Load for Size Profile Optimization Data
Allocation users have the option to select a specified store size profile to be used for
the Allocation. Using the RPAS Store Size Profile Optimization application, users have
the capability to create seasonal store size profiles and multiple store size profiles
created in SPO (called GIDs). These are displayed to the Allocation user as options to
be used.

■ Depending on what is being allocated and expected arrival date in the stores, the
Allocation user has the option to view and select the desired store size profile date
to be used.
■ All item and locations use the same store size profile data per allocation. There
cannot be unique buy item/location records within a single allocation.
■ SPO assigns a numeric generation ID number (GID) to specifically created store
size profile data. This ID, along with a user defined name should be displayed in
the Allocation user interface.
■ Only those GIDs populated from SPO to Allocation are displayed in the user
interface.
■ The retailer is responsible for updating the Allocation table on a frequent basis or
as needed.
SPO GID text files (spo_gid_label.txt) are passed along with the batch of Size Profile
Hierarchy dat file. The text file is used as the GID for that batch of dat file. Running
RETL for SPO imports data to three tables after extraction.
The RETL for SPO data file format is as follows:
<Beginning of file>
<GID>
<GID_DESC>
<End of File>
The following are examples:
GID1
Winter 2014
Table 10–5 RETL for SPO Data Physical Tables

Table Head Description
ALC_GID_HEADER The ALC_GID_HEADER table holds all generation ID
descriptions.
ALC_GID_PROFILE The ALC_GID_PROFILE table holds all generation ID profile
IDs.
ALC_SIZE_PROFILE The ALC_SIZE_PROFILE table holds all size profiles at
Style/Color, Style, Subclass, Class and Department levels.
Limitations of Oracle Retail Extract, Transform, and Load Programs

The three programs that exist for receipt plan and plan and size profile have the
following limitations:
■ The diff type is supported to a maximum of 1 character length.
■ The diff id is supported to a maximum of 10 character length.

11
11 Java Batch Process
This chapter provides an overview of the batch processes of Oracle Retail Allocation. It
also provides information about the functions of the batch processes, the Java
packages associated with the batches, and how to execute the Java-based batches.
Batch Processing Overview

Allocation contains a set of batch processes that are run in Java. Broadly, the batch
process falls under four categories:
■ Schedule Allocation batch
■ Daily Cleanup batch
■ Purge batches
■ Rule Level On Hand (RLOH) batches
■ Dashboard Refresh batch
ScheduledAllocationBatchClient.java creates the child allocations for parent allocations
that are scheduled for the day.
SessionCleanUpBatchClient.java deletes data from the temporary tables used by the
Allocations and Calculation engine.
Purge batches delete Allocation and Worksheet data from the Allocation tables, which
were created before a certain time period.
For RLOH, there are six batch update processes that share the same java batch file;
InventorySnapshotBatchClient.java.
The Dashboard Refresh batch refreshes both Stock to Sales and Top to Bottom
Dashboard reports Data.
Note the following general characteristics of Oracle Retail Allocation's java batch
process:
■ It is not accessible through a graphical user interface (GUI).
■ It is scheduled by the retailer.
■ It is designed to process large volumes of data, depending on the circumstances
and process.
Java Batch Names and Java Packages

The following table describes Oracle Retail Allocation's batch processes and its
associated Java packages:
Java Batch Process 11-1

Table 11–1 Allocation’s Batch Process and associated Java Package

Batch Name Batch Process Package
Schedule Allocation Batch ScheduledAllocationBatchCl oracle.retail.apps.alc.batch.cl
ient.java ient
Daily Cleanup Batch SessionCleanUpBatchClient. oracle.retail.apps.alc.batch.cl
java ient
Purge Batches PurgeBatchRunnable.java oracle.retail.apps.alc.batch.cl
ient
RLOH Batch Update InventorySnapshotBatchCli oracle.retail.apps.alc.batch.cl
ent.java ient
Dashboard Refresh Batch AlcDashboardCleanUp.ksh oracle.retail.apps.alc.batch.cl
ient
Running a Java-based Batch Process

To run a Java-based batch process, Oracle Retail provides sample shell scripts (.sh files)
and batch files (.bat files). These sample shell scripts must be modified according to
the retailer's installation. They perform the following internally:
■ Set up the Java runtime environment before the Java process is run.
■ Trigger the Java batch process.
Scheduler and Command Line

If the retailer uses a scheduler, arguments are placed into the scheduler.
If the retailer does not use a scheduler, arguments must be passed in at the command
line.
For UNIX systems, the Java process is scheduled through an executable shell script (.sh
file).
Note: The AllocScheduleBatch.ksh and AlcDailyCleanUp.ksh

batches can be run by an external scheduling system such as
APPWORX or a simple UNIX CRON job.
Running the Dashboard Refresh Batch

Take the following steps to run the Daily Cleanup batch:
1. Login to the application server machine using <username>/<password>.
2. Navigate to the batch folder. In the batch folder, verify that the
AlcDashboardCleanUp.ksh file is present.
3. Run the AlcDashboardCleanUp.ksh batch using the following command:
ksh AlcDashboardCleanUp.ksh <systemadministratoralias>
The batch runs by taking the batch user from wallet.
Running the Schedule Allocation Batch

Installation and build scripts create the required user for running the batch in the
wallet. There is no way you can cross check to determine whether the user is created
inside the wallet other than running the batch scripts. However, you can see if the
wallet is present in the environment by checking the wallet location. The wallet

location is present in batch.properties file. The wallet is created with a user_id,

password and an alias name.
Once the wallet is created the csm.wallet.path key in batch.properties file should be
updated.
Only those users who have their role mapped to the SYSTEM_ADMINISTRATOR_JOB
enterprise role in LDAP, have the privilege to execute the Schedule Allocation batch
script. During installation, Allocation creates the SYSTEM_ADMINISTRATOR user, by
default, in the Retail Wallet, which is mapped to the SYSTEM_ADMINISTRATOR_JOB
enterprise role in LDAP. An alias for any new user mapped to SYSTEM_
ADMINISTRATOR_JOB role in LDAP has to be created in the Wallet in order to
execute the Schedule Allocation batch script.
Note: Use the save_credential.sh script to create a new user in the

Wallet. For more information on instructions to run the save_
credential.sh script to add a new user, see the Oracle Retail
Allocation Installation Guide.
The batch.properties file exposes a few configuration parameters related to

concurrency management or parallel execution which need to be tuned by the retailer
based on the volume of transactions. The concurrent processing in batch is
implemented leveraging the standard Java Executor service APIs. The sample file with
default configurations will be made available and need to be modified by the retailer
to suit to their requirements.
The section below describes the properties that can be configured.
■ initialThreadLimit: Initial number of threads in the pool that are available to create
child allocations. The default value is 5.
■ maxThreadLimit: Maximum number of threads that can be allowed in the pool.
The default value is 10.
■ queueLimit: Size of queue of pending tasks to create child. The default value is 1.
■ providerUrl: Url of the server module (for example, t3://<weblogic host>:<port>).
This parameter has to be configured by the retailer to point to the WebLogic Server
on which Asynchronous application instance is deployed.
■ csm.wallet.partition.name: Partition name in the wallet (for example, alloc13)
■ csm.wallet.path: Location of Wallet
2. Navigate to the batch folder. If the batch folder is not found, the batch installation
did not occur properly. In the batch folder, verify that the
AllocScheduleBatch.ksh file is present.
3. Run the AllocScheduleBatch.ksh batch using the following command:
ksh AllocScheduleBatch.ksh <systemadministratoralias>
Running the Daily Cleanup Batch

Take the following steps to run the Daily Cleanup batch:

2. Navigate to the batch folder. In the batch folder, verify that the
AlcDailyCleanUp.ksh file is present.
3. Run the AlcDailyCleanUp.ksh batch using the following command:
ksh AlcDailyCleanUp.ksh <systemadministratoralias>
Running the Purge Batches

Use the following steps to run the Purge batches:
2. Navigate to the batch folder. In the batch folder, verify that the AlcPurgeAlloc.ksh
and AlcPurgeWksht.ksh files are present.
3. Run the both batch processes using the following command:
ksh AlcPurgeAlloc.ksh <systemadministratoralias> PURGE_ALLOC
ksh AlcPurgeWksht.ksh <systemadministratoralias> PURGE_WORKSHEET
Running the Rule Level On Hand Batch

Take the following steps to run the RLOH batch:
1. Login to the application server machine using <username>/<password>. Once
logged in, the default folder is /home/alcbatch.
2. Before running the batch, make sure that all the corresponding profile properties
are set. For that run the profile file first. Go to the Profiles folder inside alcbatch.
3. If there are multiple environments, there are separate profile files for every
machine (for example, QA, DEV, TEST). Make sure to identify the right profile file
here. Most likely it will be the name of the environment, run the profile file -
./alc132Linuxdev (for example, Dev 13.2 Env).
4. After running the profile successfully, go back to alcbatch. There are separate
folders for every machine’s batch under the alcbatch folder. Go to the current
machine’s folder. (Most likely the folder name would be same as your profile file
name, in this case alc132Linuxdev).
5. Run the following scripts inside the batch folder in the following order:
■ ksh AlcSnapshotSOH.ksh <BatchUserAlias>
■ ksh AlcSnapshotOnOrder.ksh <BatchUserAlias>
■ ksh AlcSnapshotAllocIn.ksh <BatchUserAlias>
■ ksh AlcSnapshotCrosslink.ksh <BatchUserAlias>
■ ksh AlcSnapshotAllocOut.ksh <BatchUserAlias>
■ ksh AlcSnapshotCustomerOrder.ksh <BatchUserAlias>
Summary of Executable Files

The following table describes the executable shell scripts and batch files:

AllocScheduleBatch Process Batch Design
Table 11–2 Scripts to initiate the deletion process

Executable Shell Executable Batch File For
Scripts (UNIX) Windows Description
AllocScheduleBatch.ksh No batch file is available Triggers the schedule batch client.
AllocBatch.ksh No batch file is available Configures the environment
variables sourced by other batch
scripts. This script is not to be
run/scheduled in a stand alone
mode.
AlcSnapshotSOH.ksh No batch file is available
AlcSnapshotOnOrder.ks No batch file is available
h
AlcSnapshotAllocOut.ks No batch file is available
h
AlcSnapshotCustomerOr No batch file is available
der.ksh
AlcSnapshotCrosslink.ks No batch file is available
h
AlcSnapshotAllocIn.ksh No batch file is available
AlcDailyCleanUp.ksh No batch file is available Deletes data from the temporary
tables.
AlcPurgeAlloc.ksh No batch file is available Deletes old Allocations from
database table
AlcPurgeWksht.ksh No batch file is available Deletes old Worksheets from
database table
AllocScheduleBatch Process Batch Design

The Allocation Auto Scheduler creates child allocations on pre-defined days of the
week set by the Allocation user within the user interface. These allocations are created
from an existing parent allocation. The auto creation of the child allocations must be
called daily via a batch process at a scheduled time, set by the system administrator.
This process needs to be scheduled to run every day (using an external scheduling
framework like APPWORKS or UNIX CRON job).
Usage
The following command runs the AllocScheduleBatch job:
AllocScheduleBatch.ksh userAlias
Detail
This script is present under the $ALLOCHOME/batch folder.
Log File
log4j.xml is present under $ALLOCHOME/properties folder. This file is edited to
specify desired log file location and name. To perform this action, change the value
against param with name="file" in log4j.xml. Make sure that folder is already present
on the file system and the batch user has write permission. Default value is set to
../logs/alloc133.log.

AlcDailyCleanUp Process Batch Design
Properties File
The default batch properties file is present under
$ALLOCHOME/properties/oracle/retail/alloc/batch.properties.
The properties below are defined. The default value may be edited.
■ initialThreadLimit initial number of threads in the pool that are available to create
child allocations. The default value is 5.
■ maxThreadLimit maximum number of threads that can be allowed in the pool.
The default value is 10.
■ queueLimit size of queue of pending tasks to create child. The default value is 1.
■ initialContextFactory specifies the JNDI context factory class (this should not be
changed).
■ providerUrl url of the server module (e.g t3://<weblogic host>:<port> ). This
parameter has to be configured by the retailer to point to the WebLogic Server on
which the asynchronous application instance is deployed.
■ csm.wallet.partition.name is the partition name in the wallet that stores the
credentials to authenticate batch user on WebLogic. For example, alloc13
■ csm.wallet.path is the path of the wallet file that stores WebLogic credentials.
Configuration
$ALLOCHOME/batch/AllocBatch.ksh should be edited by the retailer to specify
appropriate value of following environment variables
■ ALLOCHOME: directory where batch client in installed
■ JAVA_HOME: directory where JDK is installed
Assumptions and Scheduling Notes

This job should be scheduled to run every day at the same time.
AlcDailyCleanUp Process Batch Design

Allocation has a number of temporary tables that store intermediate data while
creating allocations and while performing calculations. The Daily Cleanup batch
process deletes data from these temporary tables. Run this batch immediately after
you run the Schedule Allocation batch.
This process should be scheduled to run every day (using an external scheduling
framework like APPWORKS or UNIX CRON job).
Make sure you run this process while all users are offline from the system.
Usage
The following command runs the AlcDailyCleanUp job:
AlcDailyCleanUp.ksh <BatchUserAlias>
Detail
This script is present under the $ALLOCHOME/batch folder.

AlcPurgeAlloc AlcPurgeWksht Batch Processes Design
The temporary tables which are impacted by the AlcDailyCleanUp process are as
follows:
Allocation session tables:
■ ALC_SESSION_SIZE_PROFILE_RATIO
■ ALC_SESSION_SIZE_PROFILE
■ ALC_SESSION_QUANTITY_LIMITS
■ ALC_SESSION_ITEM_LOC_EXCL
■ ALC_SESSION_ITEM_LOC
■ ALC_SESSION_GID_PROFILE_LIST
■ ALC_SESSION_GID_PROFILE
Worksheet session tables:
■ ALC_WORK_SESSION_ITEM_LOC
■ ALC_WORK_SESSION_ITEM_ALL
■ ALC_WORK_SESSION_ITEM
Temporary tables:
■ ALC_LOAD_TEMP
alc_calc_destination_temp
alc_calc_need_temp
alc_calc_rloh_temp
alc_calc_qty_limits_temp
alc_calc_rloh_item_temp
alc_merch_hier_rloh_temp
alc_calc_source_temp
alc_calc_need_dates_temp
Allocation approval tables:
■ ALC_SYNC_HEADER_TEMP
■ ALC_SYNC_DETAIL_TEMP
AlcPurgeAlloc AlcPurgeWksht Batch Processes Design

Allocation has a number of temporary tables that store intermediate data while
creating allocations and while performing calculations. The Purge batch process
deletes data from these temporary tables. Run this batch immediately after you run the
Schedule Allocation batch. This process should be scheduled to run every day using
an external scheduling framework. Make sure you run this process while all users are
offline from the system.
Along with the above mentioned capability, this batch also allows provides for
deletion of older allocations and worksheets created as a part of the Allocation
application.

Rule Level On Hand Pre-Aggregation Inventory Snapshot Batch Design
Usage
The following command runs the job:
AlcPurgeAlloc.ksh <systemadministratoralias> PURGE_ALLOC
AlcPurgeWksht.ksh <systemadministratoralias> PURGE_WORKSHEET
Details:
Allocation deletions are driven by the system option ALLOCATION_RETENTION_
DAYS. Allocations exceeding the retention parameter become purge candidates as
follows:
■ Scheduled Allocations Parents are deleted when their scheduled end date is
greater than the allocation retention days parameter.
■ Allocations that are linked to RMS allocations in the ALC_XREF table are deleted
when the RMS allocations they are linked to no longer exist in RMS.
■ Allocations that are not linked to RMS allocations in the ALC_XREF table are
deleted when they have not been modified (ALC_ALLOC.LAST_UPDATE_DATE)
for ALC_SYSTEM_OPTIONS.TP_ALLOC_RETENTION_DAYS days.
■ Allocations in Deleted status - user deleted through the UI.
Worksheets not associated to an allocation (WK worksheets) are deleted based on this
setting. Worksheets associated to an allocation (WD worksheets) are deleted when the
allocation they are related to is deleted (they follow Allocation deletion). Worksheet
deletion is driven by a system option, WORKSHEET_RETENTION_DAYS. Worksheets
purge criteria is as follows:
Worksheets not tied to an allocation (type = WK) are deleted when they are not be
modified (ALC_WORK_HEADER.UPDATED_DATE) for TP_WORKSHEET_
RETENTION_DAYS days.

This batch process addresses the most significant performance issue within the
Allocation product, the rule level on hand (RLOH) logic. This functionality requires
current and future inventory lookups for potentially entire departments.
Inventory is currently only held in RMS at the transaction level item level.
Departments in RMS can have tens of thousands of items under them. Multiply this by
the hundreds of locations that can be on an allocation and RLOH can easily end up
needing to retrieve inventory for millions of item/location combinations.
Usage
Six separate executables are called by one java batch process. The executables and the
commands to run them are as follows:
■ AlcSnapshotOnOrder.ksh
./AlcSnapshotOnOrder.ksh <BatchUserAlias>
■ AlcSnapshotCrosslink.ksh
./AlcSnapshotCrosslink.ksh <BatchUserAlias>
■ AlcSnapshotAllocIn.ksh

./AlcSnapshotAllocIn.ksh <BatchUserAlias>
■ AlcSnapshotSOH.ksh
./AlcSnapshotSOH.ksh <BatchUserAlias>
■ AlcSnapshotAllocOut.ksh
./AlcSnapshotAllocOut.ksh <BatchUserAlias>
■ AlcSnapshotCustomerOrder.ksh
./AlcSnapshotCustomerOrder.ksh <BatchUserAlias>
A remote interface can be called for each batch

public interface IInventorySnapshotCoreRemote {
public void createItemLocSOHSnapshot() throws AllocRemoteException;
public void createOnOrderSnapshot() throws AllocRemoteException;
public void createAllocInSnapshot() throws AllocRemoteException;
public void createCrosslinkInSnapshot() throws AllocRemoteException;
public void createAllocOutSnapshot() throws AllocRemoteException;
public void createCustomerOrderSnapshot() throws AllocRemoteException;

}
Each method lines up with the appropriate PL-SQL function.
Detail
Retrieving inventory requires accessing four very large RMS tables:
■ ITEM_LOC_SOH - current inventory and components of future inventory
■ ORDLOC - on order component of future inventory
■ ALLOC_DETAIL - allocation in component of future inventory
■ TSFDETAIL - crosslink transfer component of future inventory
To improve RLOH performance, four new subclass level aggregated tables are created
for use by Allocation
Table 11–3 RLOH Aggregated Tables

Table Candidate Key Source Tables
SUBCLASS_ITEM_LOC_SOH_EOD Dept ITEM_LOC_SOH
Class ITEM_MASTER
Subclass
Loc
SUBCLASS_ON_ORDER_EOD Dept ORDLOC
Class ORDHEAD
Subclass ITEM_MASTER
Loc PACKITEM_BREAKOUT
On_order_date

Table 11–3 (Cont.) RLOH Aggregated Tables

Table Candidate Key Source Tables
SUBCLASS_ALLOC_IN_EOD Dept ALLOC_DETAIL
Class ALLOC_HEADER
Alloc_in_date ORDHEAD
TSFHEAD
SUBCLASS_CROSSLINK_EOD Dept TSFHEAD
Class TSFDETAIL
SUBCLASS_ALLOC_OUT_EOD Dept ALLOC_DETAIL
Class ALLOC_HEADER
Loc ORDHEAD
Alloc_Out_Date PACKITEM_BREAKOUT
ALC_SUBCLASS_CUST_ORDER_EOD Dept TSFHEAD
Class TSFDETAIL
These tables are populated by the ALC_HIER_LVL_INV_SNAPSHOT_SQL package

(called by a batch program) nightly.
Package Details
The package that needs to be called is ALC_HIER_LVL_INV_SNAPSHOT_SQL.
SQL> desc ALC_HIER_LVL_INV_SNAPSHOT_SQL
FUNCTION ROLLUP_ALLOC_IN RETURNS NUMBER
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
O_ERROR_MESSAGE VARCHAR2 IN/OUT
FUNCTION ROLLUP_CROSSLINK_IN RETURNS NUMBER
------------------------------ ----------------------- ------ --------
FUNCTION ROLLUP_IL_SOH RETURNS NUMBER
------------------------------ ----------------------- ------ --------
FUNCTION ROLLUP_ON_ORDER RETURNS NUMBER
------------------------------ ----------------------- ------ --------
------------------------------ ----------------------- ------ --------
ROLLUP_ALLOC_OUT (FUNCTION)<return value> NUMBER OUT
ROLLUP_ALLOC_OUT
------------------------------ ----------------------- ------ --------

ROLLUP_CUSTOMER_ORDER (FUNCTION) <return value> NUMBER OUT

ROLLUP_CUSTOMER_ORDER
------------------------------ ----------------------- ------ --------
There are six functions in the package. Each of the four functions in the package
should be called by its own batch program.
■ AlcSnapshotSOH
■ AlcSnapshotAllocIn
■ AlcSnapshotOnOrder
■ AlcSnapshotCrosslink
■ AlcSnapshotAllocOut
■ AlcSnapshotCustomerOrder
Implementation
There are six different batch executables, each executable calling the appropriate
method from the above ALC_HIER_LVL_INV_SNAPSHOT_SQL package.
Clarifications on the batch functionality:
■ Each batch should state success or failure, whether an exception is caught or not.
■ There is no need for restart recovery, intermittent commits, or threading.
■ Login validation standard logic used by the scheduled alloc program should be
applied here as well.
■ The programs are run sequentially. The correct order is documented in the
Merchandising batch schedule and controlled by whichever scheduling tool used
at a particular customer.
■ There are no special security requirements for the program. Any user who can log
into the Allocation product can have the ability to run the batch processes.


12
Internationalization
21
Internationalization is the process of creating software that can be translated easily.

Changes to the code are not specific to any particular market. Allocation has been
internationalized to support multiple languages.
This section describes configuration settings and features of the software that ensure
that the base application can handle multiple languages.
Translation
Translation is the process of interpreting and adapting text from one language into
another. Although the code itself is not translated, components of the application that
are translated may include the following, among others:
■ Graphical user interface (GUI)
■ Error messages
The following components are not usually translated:
■ Documentation (Online Help, Release Notes, Installation Guide, User Guide,
Operations Guide)
■ Batch programs and messages
■ Log files
■ Configuration Tools
■ Reports
■ Demonstration data
■ Training Materials
The user interface for Allocation has been translated into:
■ Chinese (Simplified)
■ Chinese (Traditional)
■ Croatian
■ Dutch
■ French
■ German
■ Greek
■ Hungarian
Internationalization 12-1
Setting the User Language
■ Italian
■ Japanese
■ Korean
■ Polish
■ Portuguese (Brazilian)
■ Russian
■ Spanish
■ Swedish
■ Turkish
Setting the User Language

To set the language Allocation displays in, set the user language. Choose Preferences
from the drop-down menu under the user name, then choose Language in the taskbar.
There are two language settings you can choose:
■ Default: This will permanently change the language for this user. All subsequent
sessions will be in this language.
■ Current Session: This will change the language only for this session. It will revert
back to the Default the next time this user logs in.
When finished making your selections, click the Save button.
Setting Date, Time, and Number Formats

Allocation allows the user to see dates and times in a format appropriate for their own
locale, regardless what the data is stored in. Set the language Allocation displays in, set
the user language. Choose Preferences from the drop-down menu under the user
name, then choose Regional in the taskbar. There are multiple settings you can choose:
■ Territory: Choose a territory from this list. Allocation will automatically pick Date,
Time, and Number formats appropriate for that territory.
■ Date Format: Choose an option from this menu to select a date format that is
different from the default for the selected Territory.
■ Time Format: Choose an option from this menu to select a time format that is
different from the default for the selected Territory.
■ Number Format: Choose an option from this menu to select a number format that
is different from the default for the selected Territory.
■ Time Zone: Choose an option from this menu to select your time zone.
When finished making your selections, click the Save button.
Translations
Most user interface and message translations are stored in xlf files. When you select a
different language from the Preferences screen, Allocation will choose the correct xlf
file for that language.
Some translations for some drop-down menus are stored on four database tables. The
tables are RTC_LOOKUP_VALUES_TL, RTC_LOOKUP_TYPES_TL, RAF_FACET_

Translations
ATTRIBUTE_CFG_TL, and RAF_NOTIFICATION_TYPE_TL. These tables are

multilingual; all languages of these strings (English as well as all translations) are
stored in the same place.
Internationalization 12-3
Translations

13
Implementing Functional Security
13
This chapter discusses the Allocation functional security and the components used to
implement it. Allocation Functional Security is based on OPSS. For more details on
OPSS, refer to the Oracle Fusion Middleware Application Security Guide.
Access Oracle Enterprise Manager Fusion Middleware Control

Oracle Enterprise Manager Fusion Middleware Control is used to create and manage
roles and role hierarchies. The following procedures require you to access Oracle
Enterprise Manager Fusion Middleware Control:
■ Adding or Removing Members from an Application Role
■ Creating a New Application Role
■ Creating an Application Role from an Existing Role
Note: Launch Fusion Middleware Control by entering its URL into a

Web browser. The URL includes the name of the host and the
administration port number assigned during the installation. This
URL takes the following form: http://hostname:port_number/em.
The default port is 7001. For more information about using Fusion
Middleware Control, see Oracle Fusion Middleware Administrator's
Guide.
Displaying the Security Menu

Use the following procedure to display the security menu in Fusion Middleware
Control.
1. Log into Oracle Enterprise Manager Fusion Middleware Control by entering the
URL in a Web browser.
For example, http://hostname:7001/em.
The Fusion Middleware Control login page displays.
Implementing Functional Security 13-1

Figure 13–1 Logging in to Fusion Middleware Control
2. Enter the Retail Fusion application's administrative user name and password and
click Login.
The password is the one supplied during the installation of the Retail Fusion
application. If these values have been changed, then use the current administrative
user name and password combination.
3. From the target navigation pane, open the WebLogic Domain to display the
application domain (for example: APPdomain). Display the Security menu by
using one of the following methods:
■ Right-click the application domain and hover over Security in the popup
menu to display a submenu.

Figure 13–2 Displaying the Security Menu via Right-Clicking
■ From the content pane, select the application domain in the tree to open the
domain's home page. Open the WebLogic Domain menu located below the
domain's name and hover over Security to open the Security submenu.
Figure 13–3 Displaying the Security Menu via the WebLogic Domain Menu

Managing Role Hierarchy

Members can be added or deleted from an application role using Fusion Middleware
Control. Be very careful when changing the permission grants and membership for the
default application roles. Changes could result in an unusable system.
Valid members of an application role are groups, or other application roles. The
process of becoming a member of an application role is called mapping. That is, being
mapped to an application role is to become a member of an application role. Best
practice is to map groups instead of individual users to application roles for easier
maintenance.
Adding or Removing Members from an Application Role

Use the following procedure to add or remove members from an application role.
1. Log into Fusion Middleware Control, navigate to Security, then select Application
Roles to display the Application Roles page.
For information about navigating to the Security menu, see "Access Oracle
Enterprise Manager Fusion Middleware Control".
2. Choose Select Application Stripe to Search, then select the policy stripe name (for
example: ALC_PORTAL) from the list. Click the search icon next to Role Name.
Figure 13–4 Application Roles Window
The Retail Fusion Application's application roles are displayed. As an example, in

the following figure the default application roles are shown.

Figure 13–5 Viewing the Default Application Roles
3. Select the cell next to the application role name and click Edit to display the Edit
Application Role page. In the following figure the 'ALC_ALLOC_
MANAGEMENT_DUTY' role has been selected.

Figure 13–6 Editing the Application Role
You can add or delete members from the Edit Application Role page. Valid
members are application roles and groups.
4. Select from the following options:
■ To delete a member, select the member and click Delete.
■ To add a member, click the Add button that corresponds to the member type
being added to open the window. From the window, select from Add
Application Role, Add Group, and Add User.
If adding a member, complete Search and select from the available list and
click OK.
For example, the following figure shows the Add Group window after the
BUYER_JOB group has been selected.

Creating Duty Roles
Figure 13–7 Adding a Group
The added member displays in the Members column corresponding to the application
role modified in the Application Roles page.
Creating Job Roles

There are two methods for creating new Job roles:
■ Create New – Refer to the Oracle® Fusion Middleware Administrator's Guide for
Oracle Internet Directory 11g Release 1 (11.1.1) for creating new Enterprise
Roles/Groups
■ Replace with Existing – Refer to the Manage Role Hierarchy section to replace the
default Job role with existing Enterprise role/group using Fusion Middleware
Control.
Creating Duty Roles

There are two methods for creating new duty roles:
■ Create New – A new application (duty) role is created. Members can be added at
the same time or you can save the new role after naming it and add members later.
■ Copy Existing – A new application (duty) role is created by copying an existing
application role. The copy contains the same members as the original, and is made
a Grantee of the same application policy. You can modify the copy as needed to
finish creating the new role.
Creating a New Application Role

Use the following procedure to create a new application role.

Creating Duty Roles
For more information, see "Access Oracle Enterprise Manager Fusion Middleware
Control".
2. Choose Select Application Stripe to Search, and then click the search icon next to
Role Name.
The Retail Fusion Application's application roles display.
3. Click Create to display the Create Application Role page. You can enter all
information at once or you can enter a Role Name, save it, and complete the
remaining fields later. Complete the fields as follows:
In the General section:
■ Role Name – Enter the name of the application role.
■ (Optional) Display Name – Enter the display name for the application role.
■ (Optional) Description – Enter a description for the application role.
In the Members section, select the groups, or application roles to be mapped to the
application role, select Add Application Role or Add Group accordingly. To search
in the window that displays:
a. Enter a name in Name field and click the blue button to search.
b. Select from the results returned in the Available box.
c. Click OK to return to the Create Application Role page.
d. Repeat the steps until all members are added to the application role.
4. Click OK to return to the Application Roles page.
The application role just created displays in the table at the bottom of the page.
Creating an Application Role from an Existing Role

Use the following procedure to copy an existing application role.
For more information, see "Access Oracle Enterprise Manager Fusion Middleware
Control".
2. Choose Select Application Stripe to Search, and then click the search icon next to
Role Name.
The Retail Fusion Application's application roles display.
3. Select an application role from the list to enable the action buttons.
4. Click Create Like to display the Create Application Role Like page.
The Members section is completed with the same application roles, groups that are
mapped to the original role.
5. Complete the Role Name, Display Name, and Description fields.
The following figure shows an application role based upon ALC_ALLOC_
MANAGEMENT_DUTY after being named MyNewRole, as an example.

Figure 13–8 Copying an Application Role
6. Use Add and Delete to modify the members as appropriate and click OK.
The just-created application role displays in the table at the bottom of the page.

Retail applications leverage ADF's security framework that is based on the Oracle
Platform Security Services.
This section discusses the various assumptions around security for Retail
Applications.
Single Sign On (SSO) Setup for Retail Fusion Platform Applications

Retail Fusion Platform provides the following applications as enterprise archive (EAR)
files to Retail applications. By default, these applications are installing as part of Retail
applications.
1. RetailAppsAdminConsole(RAAC)
2. RetailAppsMobileSecurity
a. RetailAppsMobileBasicAuth
b. RetailAppsMobileAccessService
3. RetailAppsRESTServices
In SSO environment, follow the SSO setup procedure for these applications similar to
Retail applications.


Retail Applications allow retailers to display content from external applications. These
contents are typically business intelligence reports from a third party application that
are configured to display within the Retail Application's dashboard.
Some of these contents might be secured requiring users to login before the contents
can be accessed and displayed.
In non-SSO environments, when you log out of the Retail application, you may not be
logged out of any secured content you have configured access to. Therefore, it is
highly recommended that retailers only configure access to external content in a
SSO-enabled environments where the application logout manages the logout from any
other secured content that was previously accessed.

Alloc 160 Og

Uploaded by

Copyright:

Available Formats

Alloc 160 Og

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alloc 160 Og

Uploaded by

Copyright:

Available Formats

Oracle®

[1] Retail Allocation

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

Primary Author: Nathan Young

Value-Added Reseller (VAR) Language

Oracle Retail VAR Applications

Send Us Your Comments ....................................................................................................................... xiii

3 Back-end System Administration and Configuration

4 Security in Retail Applications

5 Web Services in Retail Applications

6 In-Context Launching Task Flows in Retail Applications

7 Customizing Retail Applications

10 Oracle Retail Extract, Transform, and Load (RETL) Batch Processing

11 Java Batch Process

13 Implementing Functional Security

Note: Before sending us your comments, you might like to check

Send your comments to us using the electronic mail address: [email protected]

Access to Oracle Support

When contacting Customer Support, please provide the following:

Review Patch Documentation

Improved Process for Oracle Retail Documentation Corrections

An updated version of the applicable Oracle Retail document is indicated by Oracle

Oracle Retail Documentation on the Oracle Technology Network

The following diagram illustrates the Allocation n-tier architecture:

Figure 1–1 Oracle Retail Allocation's n-tier Architecture

1-2 Oracle® Retail Allocation Operations Guide

Figure 2–1 Oracle Retail Allocation's n-tier Architecture

Oracle Application Development Framework (ADF)

Technical Architecture 2-1

Model-View-Controller (MVC) Architectural Pattern

Application Development Framework Security

Application Development Framework View (ADFv)

Application Development Framework Controller (ADFc)

Application Development Framework Business Components (ADFbc)

2-2 Oracle® Retail Allocation Operations Guide

Application Development Framework Model (ADFm)

Oracle Metadata Services (MDS)

Technical Architecture 2-3

Retail Fusion Platform

Allocation Backend Service

Data Access Patterns

Database Access Using ADFbc

Accessing Merchandising System Data in Real Time

2-4 Oracle® Retail Allocation Operations Guide

Managing Asynchronous Processes

Overview of Asynchronous Processes in Retail Applications

Back-end System Administration and Configuration 3-1

Figure 3–1 Asynchronous Process

Configuring JMS Resources for Asynchronous Processing

Table 3–1 WebLogic Administrator Console Resources

3-2 Oracle® Retail Allocation Operations Guide

Table 3–1 (Cont.) WebLogic Administrator Console Resources

Refer to WebLogic documentation found in

Monitoring Asynchronous Tasks Via the RAF_ASYNC_TASK Table

Table 3–2 RAF_ASYNC_TASK Table Details

Back-end System Administration and Configuration 3-3

Table 3–2 (Cont.) RAF_ASYNC_TASK Table Details

Purging the Asynchronous Tasks Table

3-4 Oracle® Retail Allocation Operations Guide