Patent Application
20130031116
Some embodiments relate to an application platform providing functionality based on business objects. More specifically, some embodiments relate to systems to populate business object instances with imported data.
An application platform may implement metadata models to support different business solutions. Metadata models may include generic models of a business object, a floorplan (i.e., a user interface layout), user interface text, a process component, and a message type, among others. A business object, for example, is a software model representing real-world items used during the transaction of business. An instance of a business object metadata model may comprise a SalesOrder object model or an Organization object model. Instances of these object models, in turn, represent specific data (e.g., SalesOrder 4711, ACME corporation).
An instance of a business object metadata model (e.g., a SalesOrder object model or, more generically, a business object) may specify business logic and/or data having any suitable structure. The structure may be determined based on the requirements of a business scenario in which the instance is to be deployed. A business application for a particular business scenario may require many business objects, where the structure of each has been determined based on the requirements of the particular business scenario.
The application platform may allow developers to create new business objects, as well as processes which utilize instances of these business objects. For example, a developer may wish to allow a user to input data into instances of a new business object. If so, the developer must manually create metadata entities to define this input, and must manually implement corresponding process agent logic in code. Moreover, an appropriate runtime configuration for handling the input must be manually established.
These manual tasks must comply with development guidelines of the application platform, and therefore require expensive developer training efforts and typically lead to long implementation times. Development errors are nevertheless likely to occur.
Application platform 110 may implement a service-oriented architecture, thereby providing services (i.e., business functionality) to service consumers. Such service consumers use this business functionality to provide user interfaces, application-to-application or business-to-business integration, output management (e.g., printing), spreadsheet download, etc. According to the illustrated embodiment, the business functionality may include retrieving, creating, modifying and/or deleting the data of business object instances stored in datastore 120. Datastore 120 may comprise any one or more systems to store business data. Such systems include, but are not limited to, relational database systems, Online Analytical Processing (OLAP) database systems, data warehouses, application servers, and flat files.
Repository 140 stores metadata defining business objects and other logical structures used by application platform 110. A developer may modify and/or create metadata within repository 140 using design application 150. Application platform 110 may create and store runtime entities based on the metadata of repository 140.
Briefly, according to some embodiments, system 100 operates to receive a selection of one or more nodes of a business object from design application 150, create a schema definition based on the selected one or more nodes, create runtime objects to map a file conforming to the schema definition to the selected one or more nodes, receive an eXtended Markup Language file from client 130 conforming to the schema definition and including instance values associated with the one or more nodes of the business object, and use the runtime objects to populate an instance of the business object with the values associated with the one or more nodes of the business object. Some embodiments of the foregoing will be described in detail below.
All processes mentioned herein may be embodied in computer-executable program code read from one or more of non-transitory computer-readable media, such as a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, and a magnetic tape, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software.
Initially, at S210, a selection of a business object is received. The selected business object may be defined by metadata of repository 140, and may comprise a standard business object (e.g., SalesOrder) provided by the provider of application platform 110, or a business object created by a developer using design application 150 and represented within metadata of repository 140. For example,
The text PDIEquipmentList.bo has been “right-clicked”, resulting in display of context menu 410. The developer, according to the present example, then selects “Create Service Integration” from context menu 410. According to some embodiments, this selection causes designer application 150 to launch a service integration wizard, the interfaces of which are shown in
Initially, the developer enters “PDIEquipmentFileInput” into interface 500 to name the present service integration (or, more specifically, input model) and indicate that the service integration represents an XML file input. Interface 600 of
Interface 600 presents all active and publicly-visible business objects of system 100, with the previously-selected business object PDIEquipmentList as selected by default. The developer may alternatively select any other business object of interface 600 according to some embodiments. The developer assigns a code to the service integration using field 610 and selects the Next button.
Returning to process 200, a selection of one or more nodes of the selected business object is received at S220. Interface 700, which is presented in response to the selection of the Next button of interface 600, provides checkboxes for receiving selections of various nodes of the selected business object at S220. In the present example, the root node is selected, thereby causing selection of each other node of the business object. According to some examples, the developer selects less than all the nodes of the business object at S220.
As will be understood, the selected nodes will dictate the structure of eXtended Markup Language files used to populate instances of the selected business object. According to the embodiment shown in
The user may then select the Next button of interface 700.
Continuing with the present example, as shown in
Selection of Activate from menu 910 also results in the creation of runtime objects corresponding to the schema definition at S240. The runtime objects are used to map an input XML file (i.e., conforming to the schema definition) to the selected one or more nodes such that instances of the nodes may be populated with values within the XML file. The runtime objects may be stored in datastore 120.
Designer application 150 may further provide interfaces 1000 through 1300 to review and redefine the created schema definition. Interface 1000 of
The schema definition itself, in XML format, is viewable via interface 1300 of
The above-described steps provide a modeled service integration that may be executed by a generic framework. Accordingly, a developer may provide population of business object instances without time-consuming and error-prone manual creation of corresponding metadata entities, process agent logic and runtime configurations. Creation and use of an XML file to populate business object instances according to some embodiments will now be described.
The images of
Images 1530 through 1550 illustrate mapping of a network drive of client 130 to one of the Web folders. Once this mapping is complete, the user may transmit the locally-stored XML file to one of the Web folders of application platform 110 by simply copying the XML file to the corresponding network drive.
Upon receiving an XML file including instance values and an identification of the service integration/schema definition with which the XML file is associated, application platform 110 may use the runtime objects created based on the schema definition to populate one or more instances of the corresponding business object with the values at S260. It may be preferable to schedule this instance population to occur at specific times such that all not-yet-processed XML files can be processed en masse.
Apparatus 1800 includes processor 1810 operatively coupled to communication device 1820, data storage device 1830, one or more input devices 1840, one or more output devices 1850 and memory 1860. Communication device 1820 may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s) 1840 may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s) 1840 may be used, for example, to enter information into apparatus 1800. Output device(s) 1850 may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.
Data storage device 1830 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory 1860 may comprise Random Access Memory (RAM).
Program code 1832 may be executed by processor 1810 to cause apparatus 1800 to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus. Datastore 1834 may store object instance data, runtime objects, schema definitions, XML files conforming to the schema definitions and including instance values, and/or any other data described herein. Data storage device 1830 may also store data and other program code for providing additional functionality and/or which are necessary for operation thereof, such as device drivers, operating system files, etc.
All systems and processes discussed herein may be embodied in program code stored on one or more computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.
Elements described herein as communicating with one another are directly or indirectly capable of communicating over any number of different systems for transferring data, including but not limited to shared memory communication, a local area network, a wide area network, a telephone network, a cellular network, a fiber-optic network, a satellite network, an infrared network, a radio frequency network, and any other type of network that may be used to transmit information between devices. Moreover, communication between systems may proceed over any one or more transmission protocols that are or become known, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).
The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations limited only by the claims.
