Skip navigation
1 2 Previous Next

Retail Support Blog

21 Posts authored by: Jennifer B-Oracle

Release Value Propositions (RVPs) outline functional details, identify major enhancements, and articulate the expected business benefits associated with a particular release. The documents are designed to help you determine whether new product features warrant upgrading from an old release or embarking on a new implementation. With this information, you will be able to initiate preliminary budget planning and begin putting together a project team to further evaluate specific Oracle products.

 

Oracle Retail is pleased to announce that the Retail 16.0 RVPs are now available on My Oracle Support through Document 2178140.1 - Oracle Retail 16.0.x Release Value Propositions (RVP)

 

Value proposition documents are available for the following components of the Retail 16.0 suite:

  • Oracle Retail Advanced Inventory Planning (AIP)
  • Oracle Retail Advanced Science Engine Cloud Services (ORASE Cloud)
  • Oracle Retail Brand Compliance Cloud Service
  • Oracle Retail Customer Engagement Cloud Services
  • Oracle Retail Demand Forecasting (RDF)
  • Oracle Retail Integration Suite
  • Oracle Retail Open Commerce Platform Cloud Service (OCP Cloud)
  • Oracle Retail Order Broker Cloud Service
  • Oracle Retail Order Broker (on premise)
  • Oracle Retail Order Management System Cloud Service (OMS Cloud)
  • Oracle Retail Merchandising Operations Management (MOM Suite)
  • Oracle Retail Predictive Application Server (RPAS)
  • Oracle Retail Planning & Optimization Cloud Services
  • Oracle Commerce - Retail Extension Module
  • Oracle Retail Store Inventory Management (SIM)
  • Oracle Retail Xstore Suite

 

O_Retail_clr_new.png

Highly available infrastructure has risen in popularity in recent years, as companies strive to match their critical computing environment’s availability to near 7x24x365 requirements.  A new case study has been published to the Oracle Retail knowledge base that describes how an Oracle Linux high-availability environment can be configured to support Oracle Retail applications. Using Oracle Fusion Middleware active-active clustering and Oracle Real Application Clusters (RAC) databases, Oracle Retail applications can be deployed in a fault tolerant computing environment to provide high availability and scalability.

 

This case study includes the following documents for Release 15.0:

 

  • Oracle Retail High-Availability Case Study Introduction
  • Oracle Retail High-Availability Case Study Oracle Linux
  • Oracle Retail High-Availability Case Study RAC (Real Application Clusters Environment)
  • Oracle Retail High-Availability Case Study Fusion Middleware Cluster
  • Oracle Retail High-Availability Case Study - Retail Applications Installation
  • Oracle Retail High-Availability Case Study - Retail Integration Suite Installation

 

For all the details, please visit Document 2151366.1 - Case Study: Creating a High Availability Environment for Oracle Retail 15.0.

 

O_Retail_clr_new.png

The Oracle Retail Xstore Suite Supplemental Documentation Library is a collection of guides, white papers, and manuals that discuss the functional and technical details of various business operations within the Oracle Retail Xstore suite of applications.   Publications are designed for and made available to Xstore administrators and programmers.

 

Some recent additions to the library include the Xstore POS and Xstore Office Development Environment Setup (Release 15.0) document, the Xstore Suite Configuration Accelerator Guide (Release 15.0), and the Xstore Suite Implementation and Security Guide (Release 15.0.1).

 

To access any of these or other Xstore functional and technical publications, please see My Oracle Support Document 1994467.1 - Oracle Retail Xstore Suite Supplemental Documentation Library

 

O_Retail_clr_new.png

Mobile devices are increasingly being used in business. This includes using a smart phone to check e-mail and connecting remotely to an office computer with a tablet. In many ways, mobile devices are powering connectivity and productivity for workers in the field.

 

Tablets represent the greatest anytime, anywhere opportunities for business mobility. By using business applications on the larger tablet screen, employees can better access all of the data they need in order to conduct business on the road.   With the release of RPAS 15.0, Fusion Client based applications are now supported for mobile devices using Apple iOS 7 and iOS 8, with Safari browser. No Flash player is required in order to run features such as Dynamic Position Maintenance or Consumer Decision Trees, as these are rendered in HTML5 on mobile devices.

 

A document is now available in My Oracle Support that provides information on the similarities and the differences between accessing RPAS applications on a PC and accessing them a mobile device in terms of ease of use, performance, and security.   Separate documents are available for RPAS 15.0 and RPAS 15.0.1.

 

For more information, please see Document 2089261.1: Oracle® Retail Predictive Application Server Using RPAS with Mobile Devices

 

O_Retail_clr_new.png

RRL Logo.jpg


The Oracle Retail Reference Library (RRL) is a collection of detailed implementation information assembled for our partners and customers, including business process models, architectural diagrams, and more. The Oracle Retail Reference Library contains deep retail intellectual property that we are sharing in order to help our customers accelerate their implementations and derive maximum value from our software. Not only do our customers get software from us, but also a wealth of information to help with their implementations.

 

The goal of the Retail Reference Library is three-fold:

  • Decrease the retailer’s time-to-value, by lessening the implementation time
  • Decrease the retailer’s total cost of ownership of Oracle Retail products, by minimizing modifications through better alignment with product direction
  • Serve as a baseline for the retailer’s differentiation—they can take more processes out-of-the-box while focusing customization efforts on the processes that differentiate them in their marketplace

         


For whom is the RRL intended?

  • Retail clients who have purchased and are implementing any of the Oracle Retail products
  • Integrators and implementers who are implementing the Oracle Retail products
  • Business analysts who want to understand how the systems can be applied to meet their business solutions
  • System analysts and system operation personnel who need additional functional understanding of the Oracle Retail products

  

A new resource is available in the My Oracle Support knowledge base that catalogs all the relevant Retail Reference Library collateral and organizes it by release.  To get more information, please see:

Document 2058843.2 - Oracle Retail Reference Library (RRL) Information Center and Release Index

   

O_Retail_clr_new.png

This announcement/alert applies to users of Retail Merchandising System (RMS) 14.1.x who utilize XITEM subscription.  There is no impact to users of previous releases of RMS.

 

The following My Oracle Support document outlines important information related to the XITEM subscription process, including mandatory changes that RMS 14.1.x customers should employ:

XItem Processing in RMS 14.1 Changed to Synchronous Mode (Doc ID 2049192.1)

 

 

For questions about this communication, or to engage an Oracle Support representative, please create a forum thread in the Oracle Retail Merchandising System User Community.

 

O_Retail_clr_new.png

The Oracle Retail software organization is announcing a new method of delivery for published release collateral associated with a given patch:  Defect Documents and Product Documentation (Release Notes, Installation Guides, User Guides, etc.).

The new publication mechanism will allow for easier maintenance and correction of defect and product documentation, as needed, by the Sustaining Engineering team. The new distribution will additionally allow customers, implementers, and Support personnel greater ease of access to the reports/documentation collateral.


For details on this important announcement, please see the following document in My Oracle Support:

Oracle Retail Announcement: New Delivery Method for Published Patch Collateral (Defect Reports, Product Documentation) (Document 2051575.1)



For questions about this announcement, please create a forum thread in the Oracle Retail Application User Communities.



O_Retail_clr_new.png

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares RPAS best practices to encourage solid RPAS design and implementation.

 

Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. In Parts 1 and 2 of this 3-part blog series, we focused on design elements of RPAS that will provide the highest levels of performance as it relates to domain partition additions and/or reclass.  In Part 3, we’ll review how to plan for a reclass in order to avoid the headaches that will be caused by inadequate disk space.

 


PART 3 of 3

 

Consider this recent example of a reclass gone awry. One Friday night about a month ago, a customer logged a Sev 1. They had kicked off a 15K item reclass, but it failed due to disk space exhaustion. The customer contacted their hardware group and had the disk mount extended from the storage pool. As evidenced in the logs, RPAS had already begun the process of copying the measure data from the source domain to the new destination, and several hundred measures had completed prior to the disk space exhaustion. Unfortunately, there were still several thousand measures still to be reclassed, and RPAS currently has no restart mechanism for a reclass that fails before completion. Since the customer’s environment now had been extended with adequate space, we simply loaded the prod.dat again. When the load finished in about 30 seconds, we knew the hierarchies indeed had already been committed to their new destination, and therefore, there was absolutely no way to continue the reclassification from the point that the disk exhausted.

 

The story above does have a happy ending because we were able to recover without going to a backup.  That is a topic for a future blog: how to recover from such a state.  And, certainly, it is possible that such a failure could lead to instances where a backup must be restored.  However, it is not a desirable state to be in and it can be avoided by proper advance planning.

 

In order to plan, it is necessary to understand what RPAS does when a reclass is performed. The RPAS hierarchy load mechanism first compares the current hierarchy loaded in the domain with the incoming prod.dat in order to determine if a reclass needs to take place. The item(s) being reclassed then are loaded into their new local domain destination and marked as active logical positions. At the same time, the item(s) will be marked as ‘inactive’ in the current local domain. A map is created from the source to the destination, and rpasDataMover commences for all registered measures that contain the reclassed dimension. However, instead of actually moving the data from the source to the destination,  RPAS copies the data. This is the reason for the additional disk space.

 

Knowing this about RPAS, how do you plan for the reclass?

 

Planning for the disk requirements of a reclass starts by finding the size of the RPAS environment without workbooks; i.e., the size of all /data directories in the global/local domains. Then, determine the % of items being reclassed as represented by “the number of items to be reclassed divided by the total items in an environment”.   Multiply the % being reclassed by the environment size.  This provides a rough estimate of how much additional disk space you will need to complete the reclass successfully. This rough estimate should be quite liberal, as certainly not every measure in the environment is reclassed; only the measures which contain dimensions for which a position has been reclassed will undertake an rpasDataMover.

 

Let’s review a quick example:

   1. RPAS Environment = 1.8TB

   2. # of items being reclassed = 12,000

   3. Total # of items in environment = 320,000

 

Additional disk space required = 1.8TB X (12,000/320,000) = 67.5 GB

 

As stated previously, RPAS copies (rather than moves) the data from the source to the destination. Thus the data associated with the ‘inactive logical positions’ in the source remains in the system. This is a departure from the earlier Position Name Indirection (PNI) design, which went to the expense of cleaning all of the measures – a very time-consuming task.  In the current design, RPAS has removed this task from loadHier in order to enhance the overall performance of reclass.  The optimizeDomain utility is responsible for deleting the stale data. The utility should be run during a window with idle system time (i.e., no users / no batch).  When executing the utility, be sure to use the '-processes' flag to ensure the highest throughput possible.


 

This concludes the 3-part blog series on design and planning considerations related to domain partition additions and/or reclass.

- Click here to revisit Part 1 of this series, which discussed partitioning considerations.

- Click here to revisit Part 2 of this series, which discussed effective use of loadHier parameters to maximize performance.

 

Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.


O_Retail_clr_new.png

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares best practices to encourage solid RPAS design and implementation.

 

Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. Below is Part 2 of a 3-part blog series which presents concepts intended to aid customers in putting forth the best design possible to ensure that the highest levels of performance are achieved when performing such actions.

 

 

PART 2 OF 3

 

By effectively using the parameters provided by loadHier, it is very possible to reduce the total reclass time by 50% or more. When performing a large reclass (such as one involving 10K+ items), this time savings could certainly make the difference when it comes to meeting an ‘Application Up’ SLA (service level agreement) for the business.

 

Although very powerful when it comes to performance optimization, the following parameters tend to be overlooked by most RPAS designers:

 

-excludeMeasList

  Path to exclude list XML file. Optimize performance by excluding this list of measures while moving data during the hierarchy reclassification process.

 

-includeMeasList

  Path to include list XML file. Optimize performance by including only this list of measures while moving data during the hierarchy reclassification process.

 


Without these parameters specified, every single measure with a base intersection that contains the reclass dimension will be invoked for a data transfer from the source domain to the destination domain -- including transferring data for calculated measures, which is a wasteful activity.

 

Therefore, the -excludeMeasList and -includeMeasList parameters should be a key part of every RPAS design in the field.  Designers should exploit this feature by telling RPAS to move data only for non-calculated measures during the reclass.  Consider the fact that after the reclass, the next likely batch job is going to be the main batch calculation sequence.  Thus, let the calculation engine perform the work of populating the data of calculated measures for the positions that have just been reclassed, and allow the reclass itself to bypass this duplication of effort.

 

A designer can quickly get a list of all calculated measures by using a 'mace –print –group' command and then piping that output to some 'grep' statements to get the LHS measures of the expressions. All rule groups with the exception of _load, _refresh, _commit should be evaluated to find the LHS measures. The 'mace –print –allGroups' should NOT be used, as this would include the rule groups just mentioned.

 

Another approach would be to utilize the “measure description” field in the Configuration Tools to describe each measure appropriately (e.g., “A calculated measure that ……” or “A loaded measure…”).  Then a command such as “printArray -array data/measdata.measinfo -slice info:description -cellsperrow 1 | grep -i calculate” would provide a list of the calculated measures.

 

 

Part 3 of this blog series will discuss space requirements for a large reclass.

Click here to revisit Part 1 of this series, which discussed partitioning considerations.



Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.

 

O_Retail_clr_new.png


 

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares best practices to encourage solid RPAS design and implementation.

 

Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. Below is Part 1 of a 3-part blog series which presents concepts intended to aid customers in putting forth the best design possible to ensure that the highest levels of performance are achieved when performing such actions.

 

Note: In general, while most information contained herein is applicable to all RPAS versions, some information is only relevant to RPAS Integer Indexing (i.e., version 13.3 and higher). 

 


PART 1 OF 3

 

When adding new partition positions to an existing environment, those positions can either be added to an existing local domain or to a new local domain. When the partition and associated base positions are added to a new local domain, RPAS does not actually create the new domain from 'scratch'.  Instead, RPAS copies the first domain that is registered within the environment. Then, RPAS removes all of the existing products from the new, copied domain and adds the new partition and its associated positions to it.

 

It is well known that RPAS environments can be very large. We regularly see local domains that range in size from 50GB to 250GB. Therefore, if the first domain in the index of your environment is very large, RPAS must copy a very large local domain to create the new domain for the new partition position. That can become very expensive not only from a performance perspective, but also from a disk perspective. The disk expense becomes even more evident in the case of Integer Indexing because that architecture only marks positions as 'logically deleted'.  Thus, the 100GB of data that was copied from the first local domain cannot be reclaimed until the optimizeDomain utility is run.  However, optimizeDomain is an expensive, time-consuming operation and should only be performed on a scheduled basis, e.g. once per quarter.

 

Given this, what can be done to mitigate the performance and disk implications?

 

To work around this situation, it is best to build your environment with a dummy partition with 1 base level position as the first indexed domain.  On the surface, this is a very simple effort.  However, keep in mind the purgeAge. Typically, a 30 day purgeAge is recommended.  After all, RPAS is not meant to be a data warehouse and the environment should only contain data relevant to current operations.  Thus, the domain will be deleted after 30 days unless you design a mechanism by which to inject the 1 dummy record into the prod.dat such that it is loaded prior to meeting the purgeAge.  Keeping the 1 dummy record in a static file and using 'cat' to append it to the incoming prod.dat should suffice.  This will keep the small, dummy domain from being deleted.

 


Part 2 of this series will discuss effectively using the LoadHier utility to improve reclass performance.



Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.


O_Retail_clr_new.png

The popular Case Study: Creating a High Availability Environment for Oracle Retail (Document 1666048.1) has been updated to include information relevant to Retail Release 14.1!

 

This case study describes how an Oracle Linux high-availability environment can be configured to support Oracle Retail applications. Using Oracle Fusion Middleware active-active clustering and Oracle Real Application Clusters (RAC) databases, Oracle Retail applications can be deployed in a fault tolerant computing environment to provide high availability and scalability. This case study includes the following documents for Releases 14.0 and 14.1:

  • Oracle Retail High-Availability Case Study Introduction
  • Oracle Retail High-Availability Case Study Oracle Linux
  • Oracle Retail High-Availability Case Study RAC (Real Application Clusters Environment)
  • Oracle Retail High-Availability Case Study Fusion Middleware Cluster (Parts 1 and 2)

 

O_Retail_clr_new.png

An important alert has been released for customers who have recently completed a full installation of Oracle Retail Store Inventory Management (SIM) 14.1.

 

To review this information, please visit My Oracle Support Document 2012365.1.

 

If you have questions about the information contained in this announcement, please create a forum thread in the Oracle Retail Store Inventory Management User Community.


O_Retail_clr_new.png

Looking for comprehensive information on the latest releases of Oracle Retail Store Inventory Management (SIM)?  Now available by popular demand, this new library provides links to functional and technical supplemental documentation (white papers, etc.) to assist you in getting the most out of your SIM installation.   The SIM Partitioning Guide and the Store Inventory Management 14.1 Ticketing Overview are the latest additions.  Check back often, as new publications will be added as they are created by Oracle Retail Application Development.


Please see:  Oracle Retail Store Inventory Management (SIM) 14.x Functional and Technical Library (Document 2003369.1)


O_Retail_clr_new.png

The Oracle Retail Tech Stack Support Notice has been updated for April 2015 and is available from My Oracle Support.

 

The Oracle Retail Tech Stack Support Notice provides the latest information regarding the Oracle Retail strategy for supporting an underlying technology stack. Information in this notice will help our customers plan for upgrades.

 

Sections in the notice list technology stack components used by Oracle Retail, including Microsoft Windows, Unix/Linux, Java, Oracle Middleware, OBIEE, and much more.   We provide advanced notice of events like upcoming discontinuation of support and changes to support, or clarifications to existing support policies.   We encourage all customers to stay informed of Oracle's strategic decisions regarding the technology components in your Retail installation by visiting the following article:

 

Document 857142.1 - Oracle Retail Infrastructure Compatibilities (With Retail Tech Stack Support Notice)


O_Retail_clr_new.png

The Oracle Retail Localization - India Requirements for Retail white paper is comprehensive enablement material that describes retail-related legislation and common business practices in India. It contains the description of all transactions that can occur in a retail business along with the related obligations in terms of tax and reporting. The paper also documents the common business practice requirements around Multiple Maximum Retail Price (MMRP) and its implications. As legislation is changing rapidly in India, the paper additionally documents recent developments for the Global Sales Tax (GST) reform which is currently in progress.


To read more about Oracle's considerations of retail-related requirements in India, be sure to visit Document 1989828.1 in My Oracle Support.


O_Retail_clr_new.png

Welcome to the My Oracle Support Community! We highly encourage you to personalize your community display name to make your activity more memorable. Please see https://community.oracle.com/docs/DOC-1022508 for instructions.