|Publication number||US7738497 B2|
|Application number||US 10/990,294|
|Publication date||Jun 15, 2010|
|Filing date||Nov 15, 2004|
|Priority date||Nov 15, 2004|
|Also published as||US8526316, US20070061427, US20100257260|
|Publication number||10990294, 990294, US 7738497 B2, US 7738497B2, US-B2-7738497, US7738497 B2, US7738497B2|
|Inventors||Nimrod Vishnia-Shabtai, Sachar Sagi|
|Original Assignee||Sap, Ag|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (4), Referenced by (2), Classifications (11), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
Embodiments of the invention described herein pertain to the field of computer software. More particularly, but not by way of limitation, one or more embodiments of the invention enable the declarative specification and dynamic updating of synchronized business information server interfaces to alter the format used in communicating with a specific data pool.
2. Description of the Related Art
The global distribution and procurement of products from manufacturers to retailers depends on the efficient exchange of information between parties involved in the supply chain. For instance, the synchronization of information that uniquely describes a product or service exchanged between trading partners is fundamental to building collaborative commercial relationships among retailers, manufacturers, and other supply chain participants. Various systems exist for synchronizing such business-to-business information between trading partners. These systems, often referred to as Global Data Synchronization (GDS) systems, are important because effective GDS systems lead to consolidation and management of master product data, which greatly increases internal supply chain efficiency. Many also consider GDS as a fundamental building block for realizing the full potential of Radio Frequency Identification (RFID) and Electronic Product Code (EPC) tags on various product configurations (e.g., pallets and cases of a particular product). GDS and EPC initiatives are designed to work together to improve business performance amongst a set of interrelated trading partners through the sharing of well-formed data that describes information associated with a set of products or services.
Business information is exchanged via repositories known as data pools that act as an interface point between supply chain entities such as manufacturers and retailers. These data pools provide a message-based framework for synchronizing item, organization and pricing data. For instance, manufacturers publish data to the data pool in accordance with a set of specific rules defined by the data pool and other parties such as retailers or other manufactures subscribed to the data pool are kept in sync with information published to the data pool.
Manufacturers publish business information to data pools and retailers subscribe to business information from data pools after the existence of a product is made known to a global directory of products known as the “Global Registry”. The global registry may then be employed by retailers to find a product and lookup the basic parameters of a product. The lookup generally includes the location of the data pool where the full product information can be found. The predominant registry in the industry is known as the “GS1 Global Registry™”. The Global Registry stores unique product identifiers (referred to as GTINs and discussed in further detail below) and location information about each of the respective parties in the supply chain (e.g., Global Location Numbers called GLNs and also discussed in more detail below). Put generally a GTIN describes what an item is and a GLN describes who has and where the item is located. The association of data pools and the Global Registry described herein are known as the Global Data Synchronization Network (GDSN).
The steps involved in exchanging business information via data pools and the global registry are as follows. First internal supplier data is reviewed and if necessary modified to conform to generally accepted standards. For instance, each product or unit of sale is given a GTIN. The GTIN provides a basis for identifying when a unit of sale passes through a retail point of sale, is delivered, ordered, invoiced, or is otherwise involved in a transaction. A GTIN comprises up to 14 digits and can be associated with raw materials or completed end user products and may also include services. The number allocated to a product needs to be communicated from the manufacturer through the supply chain in advance of transaction, so that business transactions can be set up.
A supplier of business information may also define information that uniquely identifies itself and other legal entities, trading parties and locations considered part of or needing access to supply chain information. This identifying information, typically referred to as a Global Location Number (GLN), provides a standard means of identification. The GLN is simply a 13-digit number used to uniquely identify any legal, functional or physical entity. Some examples of parties and locations that can be identified with GLNs, include but are not limited to, functional entities such as a purchasing department or customer number within a legal entity, an accounting department, a returns department, a nursing station, or any other group that performs a definable set of functions. GLNs may also act as a mechanism for identifying physical entities such as a particular room or section of a building, a warehouse, or aspects of a physical location such as a loading dock, delivery point, cabinet, or other location specific information. It is also feasible to utilize GLNs to identify buyers, sellers, companies, subsidiaries or divisions such as suppliers, customers, financial services companies, or any other entity or trading partner.
After business data is formatted for a given source data pool, it may then be uploaded to a source data pool. There are various data pools and each data pool has mandatory and optional aspects. For instance, a data pool may collect descriptive data that contains a standardized set of attributes, values, trade item information, trading partner information, product and packaging information (e.g., shipping unit information such as a pallet), consumer unit (e.g., typically a trade item in its retail form). In at least one instance attributes are used as a mechanism to name associated data (e.g., Color) and values identify the data itself associated to the attribute name (e.g., Blue). Both attributes and values can be recursive and thereby identified as a repeatable attribute/value. Any product or service having a need to retrieve pre-defined information that may be priced, ordered or invoiced at any point in any supply chain is typically referred to as a trade item. In this context, the term consumer unit is intended to indicate to the retailer that a particular item should be considered as a potential unit of sale.
In order to provide end users with a single point of entry in which to exchange business data, each data pool sends basic information about the uploaded data to the Global Registry without end user intervention. The information sent to the global registry holds the basic information and as well as the location of the supplier's data pool. Customers may search the Global Registry via their own destination data pool for information about the supplier that the customer may wish to obtain as part of its subscription to the destination data pool.
Trading partners perform the publication and subscription process for sending and receiving information via a synchronization engine that synchronizes information between each of the respective data pools. The synchronization engine allows each trading partner to maintain a single point of entry to its chosen data pool. Once implemented, GDS allows for the continuous updating of data attributes related to products for example between a plurality of computing systems in order to ensure that the data is kept identical in all locations that access the data. This synchronization process occurs in order to keep businesses up to date with changes and modifications to products and prices for example. The proper update of product data also enables a more efficient supply chain and eliminates transactions with erroneous prices or discontinued products for example.
The process of reviewing and publishing items for retail trading partners by manufacturers is in most cases a laborious process that involves development of customized applications that obtain the relevant information from the manufacture side and provide that information to the data pool in a publishable form. In addition, current systems employed in the field of global data synchronization suffer from hardcoded server interfaces that embed references to hardcoded data elements within the control logic of the application. Mixing server interface code with control logic, business logic and hardcoded data and message formats yields higher maintenance costs and increases the likelihood of errors. Furthermore, the time required to update an application is significant in that the server interface itself must be altered and sent to all users that require the modification. There is no product on the Global Synchronization Data Network market that allows for dynamic construction of server interfaces in a declarative manner. In addition, large maintenance efforts are required by a company when the format or number of parameters required by a data pool changes or when a vendor switches allegiance to another data pool. The back end processing software and server interface requires modification or a total rewrite depending on the nature of the new data pool or data pool format. Because of these and other limitations present in current systems there is a need for a dynamic server interface that is easily adjusted to interface with different data pools and can allow for users to edit declarative definitions for the server interfaces without requiring recompilation and redistribution of an application. This enables installation employees and consultants to deal with the customer specific data issues without struggling with global data synchronization issues that embodiments of the system inherently handle.
One or more embodiments of the invention enable data that is synchronized between businesses to be transferred to any desired data pool or data pool version in a format that may be declaratively specified and dynamically altered to meet the needs of the specific data pool or data pool version. The declarative server interface configurations may be dynamically altered to meet the needs of any data pool or data pool version. The ability to specify and alter a declarative server interface for example by editing an XML configuration file that is human readable allows for rapid coupling with a data pool and rapid updating of an application to meet a modification to the data pool formats. Rapid coupling to a data pool also allows for installation personnel to focus on structuring user data to comply with the data pool rather than with implementing communications protocols or application server installation issues thereby reducing the skill set required for the installation personnel. By lowering the required skill set for the installation personnel a company saves money by hiring lower wage workers to install the system.
Although a given user of a data pool usually only interfaces with one data pool, over time the data pool vendor may be replaced or the attributes and formats used in communicating with a particular data pool may change. One or more embodiments of the invention are capable of automatically detecting and altering the data and format of the data to be transferred to and from the data pool. Embodiments of the invention utilize a server interface configuration that may be dynamically altered that describes the attributes and format of each attribute as required by the data pool.
The server interface configuration may comprise an XML file in one embodiment of the invention. The XML file may be parsed with any compliant schema based or DTD based XML parser and sent to the server interface for dynamic update using JMS for example. The server interface itself may be implemented as a Resource Adapter configured to operate within the Java Connector Architecture of the Enterprise JavaBeans specification. Any communications methodology allowed by Enterprise Java in communicating with a resource adapter may be utilized in Enterprise Java related embodiments of the invention. Other embodiments of the invention may utilize other competing middleware technologies in keeping with the spirit of the invention.
In at least one embodiment of the invention an N-tier architecture may be employed comprising an Application Server. The server interface accepts an incoming server interface configuration request and utilizes information derived from the XML configuration file in order to add or remove data attributes or alter the format of the data attributes that are transferred to each data pool. In this embodiment of the invention, data pools may be switched at run-time without recompiling and redistributing the application.
On startup, the systems implementing one or more embodiments of the invention open a server interface configuration. The server interface configuration may be an XML file in one or more embodiments of the invention. The server interface configuration file is then read for declarative definitions of the data attributes and message formats required for sending information to a given data pool and for receiving from a given data pool. Processing loops until all items describing the interface have been parsed and cached for quick access at run-time.
The messages sent to and from a data pool may be sent from a component through a communications element to a server interface that forwards the messages using a data pool communications protocol. For example, an EJB component may send a message to a message queue communications element to a server interface that forwards a message to a data pool using the AS2 communications protocol. Alternatively an EJB component may instantiate a resource adapter that communicates with a data pool using an alternative communications protocol. A server interface that utilizes dynamic server configurations with other communications elements, component types and data pool communications protocols is in keeping with the spirit of the invention.
A system and method for dynamically modifying synchronized business information server interfaces will now be described. In the following exemplary description numerous specific details are set forth in order to provide a more thorough understanding of embodiments of the invention. It will be apparent, however, to an artisan of ordinary skill that the present invention may be practiced without incorporating all aspects of the specific details described herein. In other instances, specific features, quantities, or measurements well known to those of ordinary skill in the art have not been described in detail so as not to obscure the invention. Readers should note that although examples of the invention are set forth herein, the claims, and the full scope of any equivalents, are what define the metes and bounds of the invention.
One or more embodiments of the invention enable data that is synchronized between businesses to be transferred to any desired data pool or data pool version in a format that may be declaratively specified and dynamically altered to meet the needs of the specific data pool or data pool version. The data pool vendor utilized by a company or the attributes and formats used in communicating with a particular data pool may change over time. One or more embodiments of the invention are capable of automatically detecting the changes to the server interface configuration and altering the data and format of the data transferred to and from a data pool.
The server interface configuration may comprise an XML file in one embodiment of the invention. The XML file may be parsed with any compliant schema based or DTD based XML parser and read by the server interface at initialization time or sent to the server interface for dynamic update using JMS for example. The server interface itself may be implemented as a Resource Adapter configured to operate within the Java Connector Architecture of the Enterprise JavaBeans specification. Any communications methodology allowed by Enterprise Java in communicating with a resource adapter may be utilized in Enterprise Java related embodiments of the invention. In at least one embodiment of the invention an N-tier architecture may be employed comprising an Application Server. The server interface accepts an incoming server interface configuration request and utilizes information obtained from the XML configuration file in order to add or remove data attributes or alter the format of the data attributes that are transferred to each data pool. In this embodiment of the invention, data pools may be switched at run-time without recompiling and redistributing the application.
A Server Interface instance may obtain a server interface configuration file in any number of ways such as obtaining the file at initialization or during run-time via JMS or as a web service or any other mechanism of transferring a description of the required data pool data attributes and formats. The architecture of
The protocol used in communicating with a data pool in the GDSN is determined by the communication protocols accepted on that network, such as the AS2 communications standard for example. As the examples shown in
The following message types are required for communicating with the GDSN as of Aug. 1, 2004: Registry Catalogue Item, Catalogue Item Subscription, Catalogue Item Notification, Catalogue Item Confirmation, Response for Registry Catalogue Item, Party messages, Business Exception, Acceptance Acknowledgement, Catalogue Item Registration Acknowledgement, Receipt Acknowledgement. Of these messages, the “Catalogue Item Synchronization” message is the message that is used within the GDSN in order to publish data to a data pool.
Thus embodiments of the invention directed to a global data synchronization dynamic server interface have been exemplified to one of ordinary skill in the art. The claims, however, and the full scope of any equivalents are what define the metes and bounds of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6341316 *||Apr 28, 2000||Jan 22, 2002||Avantgo, Inc.||System, method, and computer program product for synchronizing content between a server and a client based on state information|
|US6466947 *||Mar 20, 1998||Oct 15, 2002||Sun Microsystems, Inc.||Apparatus and method for dynamically verifying information in a distributed system|
|US7275243 *||Mar 21, 2003||Sep 25, 2007||Sun Microsystems, Inc.||Mobile download system|
|US7350226 *||Sep 13, 2002||Mar 25, 2008||Bea Systems, Inc.||System and method for analyzing security policies in a distributed computer network|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US9223844||Mar 28, 2013||Dec 29, 2015||International Business Machines Corporation||Dynamically synching elements in file|
|US20130290851 *||Oct 12, 2012||Oct 31, 2013||Microsoft Corporation||User interface web services|
|U.S. Classification||370/503, 715/735, 709/221|
|Cooperative Classification||G06F17/30569, G06Q30/0633, G06F17/30575, G06F17/30|
|European Classification||G06F17/30S5V, G06F17/30S7, G06Q30/0633|
|Jun 20, 2005||AS||Assignment|
Owner name: SAP, AKTIENGESELLSCHAFT, GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VISHNIA-SHABTAI, NIMROD;SAGI, SHACHAR;REEL/FRAME:016363/0622
Effective date: 20050619
Owner name: SAP, AKTIENGESELLSCHAFT,GERMANY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VISHNIA-SHABTAI, NIMROD;SAGI, SHACHAR;REEL/FRAME:016363/0622
Effective date: 20050619
|Nov 25, 2013||FPAY||Fee payment|
Year of fee payment: 4
|Aug 26, 2014||AS||Assignment|
Owner name: SAP SE, GERMANY
Free format text: CHANGE OF NAME;ASSIGNOR:SAP AG;REEL/FRAME:033625/0334
Effective date: 20140707