Method and system for implementing versions of a sales catalog

Described is an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application. Version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog. Each of the sales catalog versions is associated with a unique identifier, where one of the identifiers is recognized as the “run-time” version identifier. The sales catalog having the recognized run-time identifier value is visible to and accessible to the ordinary users of the system as the runtime sales catalog. All other sales catalog versions associated with other identifiers are not visible/accessible to ordinary users.

BACKGROUND

The present application relates to software development and more specifically to systems, methods, and patterns for implementing enterprise software applications.

Many types of business logic are implemented by enterprise software applications. For example, CRM applications often implement business logic to perform price quotations and order capture for customers. For the price quotation business logic, a pricing engine may be implemented to receive input data (e.g., product name or product ID) and to return output data that includes the price for each product in the input data. For the order capture business logic, an order capture engine and/or eligibility engine may be used to receive input data regarding a potential order (e.g., customer ID and product ID) and provide output data regarding the order capture or order eligibility.

A sales catalog comprises the set of data commonly accessed by a CRM system. The sales catalog includes information relating to the products offered for sale by the company, such as pricing information, product descriptions, product images, and the like.FIG. 2provides an illustration of an example interface200that displays a list of product details that may be captured within a sales catalog. The sales catalog may be accessed, for example, by the business logic that is used to perform price quotations and order capture for customers.

There will be occasions when the sales catalog may need to be updated. For example, the sales catalog may need to be changed when a company needs to change pricing, revise product offerings, or change product descriptions for its offerings. Authoring, updating, and publication of a new version of the sales catalog can be a very iterative and time consuming process involving cooperation of multiple users. The problem is that until the changes have been finalized, the production users of the system should not normally be permitted to access the in-progress state of the sales catalog being modified. Otherwise, premature access to the in-progress data can lead to data inconsistencies, collisions, or conflicts. Therefore, careful orchestration of the editing and publishing processes is a complex task that needs careful coordination to avoid these types of problems. This is needed to ensure that while the publishing process is running (e.g., a long running asynchronous process), production users are prevented from making any modifications to the set of product groups that are being published.

SUMMARY

Some embodiments of the invention provide an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application. Version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog. Each of the sales catalog versions is associated with a unique identifier, where one of the identifiers is recognized as the “run-time” version identifier. The sales catalog having the recognized run-time identifier value is visible to and accessible to the ordinary users of the system as the runtime sales catalog. All other sales catalog versions associated with other identifiers are not visible/accessible to ordinary users. Once the updates have been made to the non-runtime version of the sales catalog, that updated sales catalog can be recognized by the system as the new runtime sales catalog by swapping the version number associated with that updated version to be the new runtime version.

Other and additional objects, features, and advantages of the invention are described in the detailed description, figures, and claims.

DETAILED DESCRIPTION

The embodiments of the invention provide an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application.

According to some embodiments, version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog. In effect, each of the sales catalog versions is associated with a unique identifier, where one of the identifiers is recognized as the “run-time” version identifier. The sales catalog having the recognized run-time identifier value is visible to and accessible to the ordinary users of the system as the runtime sales catalog.

All other sales catalog versions associated with other identifiers are not visible/accessible to ordinary users. The non-runtime versions can therefore be updated and/or operated upon without having any effect upon the access by users to the runtime version of the sales catalog. Once the updates have been made to the non-runtime version of the sales catalog, that updated sales catalog can be recognized by the system as the new runtime sales catalog by designating the version number associated with that updated version to be the new runtime version.

This “swap” of the version numbers by the system therefore provides a very quick and extremely efficient way to make the new version of the sales catalog available to the users of the system. This approach allows updates to be performed with only minimal impact upon users, since the admin versions of the catalog can be operated upon without impairing access by users to the sales catalog. In addition, once the updates have been performed, the swapping action only needs to be performed upon a small amount of data (the runtime identifier value -- and not the entirety of the data volume for the sales catalog), which allows the swap of the admin version to be the new runtime version to be performed extremely quickly.

FIG. 1shows an architecture of a system100for implementing and coordinating versions of a sales catalog according to some embodiments of the invention. System100may include one or more users at one or more user stations102a, where the users operate the system100to access and utilize applications (e.g., CRM applications) on an application server118to perform any activities operable using the application server118. The CRM application on application server118may be used to access a sales catalog132ain a database110.

The user may use a sales catalog admin tool108to author, modify, or update the data within the sales catalog.FIG. 2illustrates an example interface200for editing the contents of the sales catalog. Any suitable type of type of editing may occur to the sales catalog. For example, editing may occur to add new products to the catalog, change product hierarchies, modify catalog behavior and engine associations, and change parameters and details for products.FIG. 3illustrates an example interface300showing sales catalog objects accessible through an admin tool.

During the authoring process, the workspace will include an admin version132bof the sales catalog object. The admin version132bis associated with a version number indicative of the object being an admin version (rather than a run-time version). Similarly, the runtime version132ais associated with a different version number indicative of the object being a runtime version (rather than an admin version). When ready for publication, a swap will occur for the version numbers associated with both the run-time version132aand the admin version132b. This swapping action is implemented by swapping only the single run-time version number indicator (but not the data stored across the content). This swap of the version numbers operates to effect publication of the new version in the workspace as the new run-time version of the sales catalog.

In system100, user station102acomprises any type of computing station that may be used to operate or interface with a server118. Examples of such user stations102include for example, workstations, personal computers, laptop computers, or remote computing terminals. User station102amay also correspond to any type of portable tablet device, including for example, tablet computers, portable readers, smartphones, and/or programmable mobile handsets. The embodiments of the invention are applicable to any computing device that works in conjunction with an application that access a sales catalog or other forms of CRM data.

The user station102acomprises a display device, such as a display monitor or screen, for displaying scheduling data and interface elements to users. The user station102amay also comprise one or more input devices for the user to provide operational control over the activities of system100, such as a mouse, touch screen, keypad, or keyboard. The users of user station102acorrespond to any individual, organization, or other entity that uses system100to access applications on application server118, such as a CRM application on application server118.

The database110corresponds to any type of computer readable mediums or storage devices. The computer readable storage devices comprise any combination of hardware and software that allows for ready access to the data within database110. For example, the computer readable storage device could be implemented as computer memory or disk drives operatively managed by an operating system.

FIG. 4illustrates a flowchart of an approach to implement some embodiments of the invention. This approach in some embodiments is implemented by having a base object for the sales catalog having a header table and a large number of child tables. The record on the header table has two key version related fields, where they have different values at any time,0or1: (i) Admin_Version_Number and (ii) Runtime_Version_Number.

In addition, each child table has two set of records with different version numbers—a -version “1” and a version “0”. One version is for the runtime version and the other is a workspace version for admin purposes. The Admin_Version_Number and Runtime_Version_Number on the base object will indicate which version is visible to runtime and which version is used by the admin tool for editing as workspace.

At402, authoring, updating, and/or modification of the sales catalog are performed by modifying the admin version of one or more objects. The admin version is the version of the object associated with the appropriate version number indicative of being an admin version in the workspace.

At404, after all edits have been performed and the appropriate validations have occurred, the admin version is ready to be published as the new runtime version of the sales catalog objects. During publish time, a single short transaction will be used to swap the admin_version_number and runtime_version_number on the base object being published. This swapping of the version numbers will make the old workspace version to become runtime version.

At406, post synchronization tasks can be performed against the sale catalog objects. The post synchronization process can be used, for example, to slowly copy the new runtime version content to the new workspace version so that they will be in sync. As this only changes the new workspace version, this process should not impact runtime performance of the system.

FIGS. 5A-Dillustrate this process according to one embodiment.FIG. 5Ashows the system100, where one or more users at user station102ais currently using a CRM application on application server118to access the runtime version132aof the sales catalog in a database110. An admin version132bof the sales catalog also exists in a workspace. The runtime version132ais associated with the appropriate version number (e.g., version number “1”) to indicate that it is the run-time version of the sale catalog. The admin version132bis associated with the appropriate version number (e.g., version number “0”) to indicate that it is the admin version of the sale catalog.

FIG. 5Billustrates when a user is using the admin tool108to edit the contents of the admin version132bof the sales catalog in the workspace. At this point, the production users at the user station102aare isolated from the admin version132bof the sales catalog. This is because the admin version132bis still associated with the version number indicative of the object being an admin version (rather than a run-time version). Similarly, the runtime version132ais still associated with a different version number indicative of the object being a runtime version (rather than an admin version).

When ready for publication, a swap will occur for the version numbers associated with both the run-time version132aand the admin version132b.FIG. 5Cillustrates this swapping process. Version132ahas its version number changed from “1” to “0”. Similarly, version132bhas its version number changed from “0” to “1”.

As shown inFIG. 5D, this swap of the version numbers operates to effect publication of the new version in the workspace as the new run-time version of the sales catalog. This is because the new run-time version132b(formerly admin version) is now associated with the appropriate version number (e.g., version number “1”) to indicate that it is the run-time version of the sale catalog. The new admin version132a(formerly runtime version) is associated with the appropriate version number (e.g., version number “0”) to indicate that it is the admin version of the sale catalog.

FIGS. 6A-Dillustrate this process according to another embodiment.FIG. 6Ashows the system100, where one or more users at user station102ais currently using a CRM application on application server118to access the runtime version132aof the sales catalog in a database110. An admin version132bof the sales catalog also exists in a workspace. The runtime version132ais associated with a given version identifier (e.g., version ID “1”). The admin version132bis associated with the another version identifier (e.g., version ID “0”).

Metadata131exists in the system to identify which of the sale catalog versions is currently the runtime version. Here, the runtime ID metadata131indicates that the sales catalog associated with a version ID value of “1” (i.e., sales catalog runtime version132a) is the current run-time version of the sale catalog. All other sales catalogs having other version ID values are non-runtime versions (i.e., admin version132b).

FIG. 6Billustrates when a user is using the admin tool108to edit the contents of the admin version132bof the sales catalog in the workspace. As before, the production users at the user station102aare isolated from the admin version132bof the sales catalog, since the admin version132bis still associated with the version number indicative of the object being an admin version (rather than a run-time version). Similarly, the runtime version132ais still associated with a different version number indicative of the object being a runtime version (rather than an admin version).

When ready for publication, a swap will occur for the version numbers associated with both the run-time version132aand the admin version132b.FIG. 6Cillustrates this swapping process, where the metadata131has its runtime ID value changed from “1” to “0”. This swap therefore identifies sales catalog version132a(which is associated with ID value “0”) as the new runtime version of the sales catalog. This also identifies sales catalog version132a(which is associated with ID value “1”) as no longer being the runtime version.

As shown inFIG. 6D, this swap of the version numbers operates to effect publication of the version132binto the workspace as the new run-time version of the sales catalog. This is because the new run-time version132b(formerly admin version) is now associated with the appropriate version number (e.g., in metadata131) to indicate that it is the run-time version of the sale catalog. The new admin version132a(formerly runtime version) is associated with the appropriate version number (e.g., version number “1”) to indicate that it is the admin version of the sale catalog.

In these embodiments, the admin change on the base objects is not visible to the runtime user interface (UI) until published, where the change on the base objects may contain changes that span across many (e.g., 20+) child tables. The product group may need to generate a large number of derived objects (such as denormalization tables) for efficient runtime query, where the derived object are not be visible to runtime UI until same admin change published. This invention supports operations of systems that require extensive validation to be run on derived object and base object which is time consuming, since the derived objects are separated from production users until published. In addition, the approach will not block the runtime UI while the derived object generation and validation is being performed. Within a single publish event, there may be involvement of any number of base objects, where the derived object creation is incremental and will not require unnecessary changes.

The above-described approach(es) are described as being applicable to perform versioning on base objects. Embodiments of the invention can also be applied to perform versioning on derived objects. In these embodiments, the derived object will have two version related field, where both has a value of either 1 or 0:Runtime_StatusAdmin_Status

The runtime user interface (UI) only look at records with the appropriate identifier value (e.g., RuntimeStatus=1). Therefore, any object that does not have RuntimeStatus=1 will not be displayed to the user. During derived object generation, the system slowly prepares the derived object, and the new record is added with RuntimeStatus=0 and AdminStatus=1. Since RuntimeStatus=0 for the new derived object, the runtime UI will not access this object for display to the user.

During activation time, within the same transaction of the base object version flipping and for those changed derived object, the system will copy the AdminStatus value to the RuntimeStatus value. Since the new derived record corresponds to RuntimeStatus=0 and AdminStatus=1, copying the AdminStatus value to the RuntimeStatus value will result in the derived record corresponding to RuntimeStatus=1 AdminStatus=1. This will make the derived object available to end user in one shot.

To delete an existing derived object, the system sets the value of AdminStatus=0 on the old derived object. During activation, this value for Adminstatus will make the object inactive.

To modify existing derived object, one can set AdminStatus=0 on the old derived object. A copy of it can be crated with modifications and values set for RuntimeStatus=0, AdminStatus=1 on the new copy.

In some embodiments, one cannot use the same approach for the base object as for the derived object. The system will not maintain two full copies of data. This is in contrast to the approach is which, in base object case, each child table has two full copies, e.g., for the admin version and runtime version.

The embodiments of the invention also provide an approach to identify the object(s) to publish. In this approach, the header of the base object and the derived object both have a batch key field to indicate whether it is part of current publish/activation job. A unique batch job key number is generated when starting a job to perform the publish operation. The base object selected to be part of job will be tagged with this batch key. When derived objects are generated, those objects been touched will be tagged with this batch key. On the final flip activation phase, the batch key can be used to identify the set of objects need to be flipped.

A lock mechanism can be implemented so that the base object will only be involved in one admin editing and batch job at any time. In some embodiments, concurrency control is performed where only one batch at a time is allowed to generate derived object. Although it is possible to relax the concurrency control enforcement to allow different batch to modify different set of the derived objects, this may require more complex handling to manage derived object generation.

Validations may be performed of the base and derived objects before activation. It is noted that both the base object and derived object have been tagged with the batch key and runtime/admin version number/status. By combining these criteria, one can query the published view of the derived object to perform a cross-validation. In effect, the criteria on the derived object to query the pre-published version of data is in some embodiments:

RuntimeStatus=1 and BatchKey is not current Batch

AdminStatus=1 and BatchKey is current Batch

Therefore, what has been described is an improved approach to implement versioning for enterprise applications, such as sales catalogs accessed by CRM systems. The embodiments of the invention provide an improved approach for implementing a handshake mechanism to permit effective versioning and updates for data within an enterprise application. According to some embodiments, version numbers are associated with sales catalog objects, where the appropriate version number is associated with the specific object to be published as the run-time object for the sales catalog.

System Architecture Overview

Computer system1400may transmit and receive messages, data, and instructions, including program, i.e., application code, through communication link1415and communication interface1414. Received program code may be executed by processor1407as it is received, and/or stored in disk drive1410, or other non-volatile storage for later execution.