Patent Application
20100161731
Traditional enterprise application development may be divided into two categories: best-practice based, and customer-specific development. Best-practice based enterprise application development provides generic solutions based on the best practice of certain industries and/or business domains. The majority of enterprise application vendors, such as SAP™, Oracle™, and Salesforce™ take this approach. Due to the massive user base, the development with this approach can reduce costs while providing software of good quality. However, customers of this category can only distinguish their business processes through limited customizations. Customers end up using the vendors' business processes, rather than their own.
Business processes are valuable assets in a company, especially in companies with effective business processes and/or long history. A customer-specific enterprise application is developed for a specific customer. Therefore, it should meet the exact needs of a specific customer. Companies such as WalMart and Dell adopt this approach. However, a customer-specific business application normally costs more and the coding quality may be poor due to the limited user base. As business competition increases, customers seek business applications that are developed specifically for their business needs, but with low cost and high code quality.
More and more business solutions need to cross organizational boundaries internally and externally. New business solutions need to integrate with existing enterprise applications. It is difficult to make a data model from a vendor fit one from another vendor. It may even be difficult to make a data model from one system fit another system from the same vendor. Therefore, new business solutions require business processes with flexible and extensible data models.
There is an ongoing need for new business application development systems that can support customer-specific development with good code quality and low cost.
In the drawings, the same reference numbers and acronyms identify elements or acts with the same or similar functionality for ease of understanding and convenience. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.
References to “one embodiment” or “an embodiment” do not necessarily refer to the same embodiment, although they may.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “above,” “below” and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. When the claims use the word “or” in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
Overview
Described herein is a document-centric architecture for enterprise application development. This architecture separates an enterprise application system into two parts: platform and community. The platform supports a document-centric infrastructure that provides infrastructure level implementations based on documents, including UI, workflow, business rules, accessing permission, internationalization, event triggering and event subscription, integration and customer process specific code. Customer process specific data are the configurations with the components mentioned above. These configurations are provided in community. The implementation of the components in platform is well designed and well developed so that the code quality is good. As the data schema and business process are defined in the community, the enterprise application developed with the document-centric architecture can support customer specific processes.
A new system for developing business applications is described which meets customers' specific business needs while providing for good quality, low development cost, and rapid development.
In this new system, a data schema for documents is defined by customers. This fundementally differs from traditional enterprise application development techniques that employ predefined data schemas with limited customization. An enterprise application is divided into two parts: platform and community. The “platform” part provides the infrastructure implementation. The “community” provides customer-specific configurations, such as definitions for components and services, and data schemas and customer specific code (such as addins, filters, and event handlers).
The majority of the functionality implementation and the architecture of the system is provided by the platform logic. Different enterprise applications may use the same platform with different communities. As more enterprise applications are developed, the quality of the platform improves. Reuse of the platform logic means quality can be maintained to a high standard.
The development cost is reduced because only the community component is changed for new applications. The platform provides the base infrastructure. Developers of an enterprise application see results immediately once they implement the community component.
Enterprise application development begins with documents. The enterprise application comprises a set of document types. A document template implements a document type; for example, a transaction document or a master data document template. In one embodiment, a document type comprises multiple zones, including a single primary zone, and multiple detail zones. Attributes and zones may be categorized. There are a variety of attributes, including String, Float, Note, Image, and functions. An object relational mapping for a document may be automatically generated once the document template is defined.
A “portal” may be employed to add and remove predefined porlets and arrange the layout for portlets. A web portal may act as a gateway for users to access functionalities of an enterprise application, Types of portals include general portals and specialized or niche portals. Some major general portals include Yahoo™, CNET™, AOL™, and MSN™ Third party applications may interact with the enterprise application through an integration channel. “Portlets” are pluggable user interface logic components that are managed and displayed in a portal. A portlet is generated automatically from a document type and document template.
Multiple level event triggering and processing is supported. Events may be processed closer to where they are generated. Low level events may be reported and aggregated to high level events.
Internationalization is supported based on document templates.
Document template integration is supported with a varity of external data sources, such as FTP, web service, RSS, HTTP, and database. Syntactic and semantic validation is provided for document templates.
All the configuration and definition for document type, document template, portlet, event definition, workflow, and access permission may be defined as metadata using, for example, XML. In one embodiment, platform and community logic are built with Java technology. Implementation may also be accomplished with other technologies, such as Microsoft® “Dot net”® technology.
The term “enterprise application” refers to device logic that when put into operation on a data processing machine or machines facilitates techniques described herein.
Members of the business community may each comprise data processing devices to interact with the enterprise application logic. For example, the retailer may comprise devices 102, 103, the manufacturer device 106, and the distributer device 105. Of course, the number and distribution of devices among community members will vary in specific deployments.
The application logic may operate across organizational boundaries. Permissions, workflow, user interface, events, notifications, and collaboration may all span organization boundaries.
The logic to form an association between multiple memory regions each representing a document zone may operate responsive to a metadata definition for the document zones. An example of such a metadata definition is provided in Listing 1.
A Header Zone “AAA_PO_HDR” for document template “AAA_PO” is defined in Listing 1. The display name of this zone is “Purchase Order Header”. This header zone has seven data elements: “order_num”, “supplier_name”, “order_date”, “ship_to”, “receipt_type”, “notes” and “attachments”.
In Listing 1, an element may have the following attributes: name, type, mandatory, search, updatable, generate-business-key, doc-template-ref, zone-ref, collaborate, values and default-value. Mandatory, search, updatable, and collaborate have Boolean value: “yes” or “no” to decide whether the element will support the specific feature. Doc-template-ref and zone-ref are the reference to document template and zone. Values contain all the potential values and default-value is the default value which should be of the potential values.
The logic to form an association between multiple memory regions, each memory region representing a document zone, may form at least one zone comprising multiple associations to user interface attributes. This may be referred to as a user interface (UI) zone or template. The machine-data contents of this zone may be applied to logic that affects graphics operations of the device according to the user interface attributes, to form a configuration of pixels on a display device (e.g. a ‘user interface’ representing a ‘document’). Listing 2 is an example of metadata that may affect the operation of logic to form a configuration of document pixels on a display device.
Listing 2 defines a user interface (UI) template “UI_PO_TMPL” which comprises two UI Zones: “UI-PO-HDR” which is a primary zone; and “UI-PO-DETAIL” which is a detail zone. In one embodiment, a document UI may have a single primary zone and multiple detail zones. In Listing 1 there is a single detail zone. One zone can have multiple UI groups. In this example, the primary zone “UI_PO_TMPL” has only one group and the detail zone “UI-PO-DETAIL” has multiple detail zones. One zone comprises multiple elements: ui-element name, collapse, ui-type, field-width and element-ref. Element element-ref references the attribute reference name.
The enterprise application may include logic to relate memory regions each representing an attribute with one another, where the memory regions representing attributes are each associated with different associated document zones. In other words, attributes in different document zones of the same document object may be related to one another.
The enterprise application may include logic to relate memory regions each representing an attribute with one another, where the memory regions representing attributes are each are associated with different unassociated document zones. In other words, attributes in document zones of different document objects may be related to one another.
The enterprise application may include logic to represent in memory one or more conditions against which to evaluate a format or value of data in each of the memory subregions. In other words, the enterprise application may include logic to perform semantic and/or data validation of document zone attributes.
Machine data representing attribute features may be represented in a memory region separate from a particular document or document zone memory object. The enterprise application may include logic to associate multiple subregions of each document zone with memory regions in a central catalogue of document attributes (see
One machine action that may be represented by a workflow node is creation of a new document object memory configuration. An enterprise application may thus include logic to form a memory region representing an action that activates logic (1) form an association between multiple memory regions each representing a document zone, (2) form memory regions representing collaborative states for each zone and to maintain the collaborative states independently of other zones, and (3) form memory regions representing workflow states for each zone and to maintain the workflow states independently of other zones.
One of the actions that may be represented by a workflow node is a communication event, such as a notification in the form of an email or other visual or auditory event. An enterprise application may thus include logic to form a memory region representing an action to activate a machine device communication event.
Collaborative flows and workflows may be shared among document zones. Enterprise application logic may thus include logic to make multiple associations between workflow memory configurations and/or collaborative memory configurations and multiple memory region configurations representing document zones. The zones may be in different document objects. In practice, this may involve forming an association between first multiple memory regions each representing zones of a first document, forming memory regions representing collaborative states for each zone of the first document, forming memory regions representing workflow states for each zone of the first document, forming an association between second multiple memory regions each representing zones of a second document, associating with one or more of the second multiple memory regions representing the zones of the second document, one or more of (1) memory regions representing collaborative states for a zone of the first document, or (2) memory regions representing workflow states for a zone of the first document.
Workflows may be shared among document zones, and thus the enterprise application logic may form multiple sets of linked memory regions, each set representing a workflow state, and associate each set of linked memory regions with a different memory region representing a document zone.
The logic to form memory regions representing collaborative states for each zone and to maintain the collaborative states independently of other zones may act responsive to a metadata definition for the collaborative states. Likewise, the logic to form memory regions representing workflow states for each zone and to maintain the workflow states independently of other zones may be responsive to a metadata definition for the workflow states. Listings 3 and 4 are examples of metadata definitions to define collaborative and workflow states and rules.
Listing 3 includes a definition of the rule “createReceiptDoc”. In this example, when the condition primary gets satisfied, a document will be created and an event “ReceiptCreated” will be generated.
Listing 4 gives the metadata definition of the workflow represented in
Implementations and Alternatives
“Logic” refers to signals and/or information embodied in circuitry (e.g. memory or other electronic or optical circuits) that may be applied to influence the operation of a device. Software, hardware, electrical and optical memory, and firmware are examples of physical structure that may embody logic. Hardware logic may be embodied in circuits. In general, logic may comprise combinations of software, hardware, and/or firmware.
“Metadata definition” refers to a set of machine data values represented as alpha-numeric text, which may be applied to affect the operation of device logic to form memory associations and states.
“Memory region” refers to one or more machine memory circuits maintaining an electrical or optical configuration representative of a data value. The circuits of a machine memory need not necessarily be associated with contiguous ‘addresses’ in a memory circuit, although they may, depending upon the implementation.
Those skilled in the art will appreciate that logic may be distributed throughout one or more devices, and/or may be comprised of combinations of instructions in memory, processing capability, circuits, and so on. Therefore, in the interest of clarity and correctness logic may not always be distinctly illustrated in drawings of devices and systems, although it is inherently present therein.
The techniques and procedures described herein may be implemented via logic distributed in one or more computing devices. The particular distribution and choice of logic is a design decision that will vary according to implementation.
Those having skill in the art will appreciate that there are various logic implementations by which processes and/or systems described herein can be effected (e.g., hardware, software, and/or firmware), and that the preferred vehicle will vary with the context in which the processes are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a hardware and/or firmware vehicle; alternatively, if flexibility is paramount, the implementer may opt for a solely software implementation; or, yet again alternatively, the implementer may opt for some combination of hardware, software, and/or firmware. Hence, there are several possible vehicles by which the processes described herein may be effected, none of which is inherently superior to the other in that any vehicle to be utilized is a choice dependent upon the context in which the vehicle will be deployed and the specific concerns (e.g., speed, flexibility, or predictability) of the implementer, any of which may vary. Those skilled in the art will recognize that optical aspects of implementations may involve optically-oriented hardware, software, and or firmware.
The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood as notorious by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in standard integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of a signal bearing media include, but are not limited to, the following: recordable type media such as floppy disks, hard disk drives, CD ROMs, digital tape, and computer memory; and transmission type media such as digital and analog communication links using TDM or IP based communication links (e.g., packet links).
In a general sense, those skilled in the art will recognize that the various aspects described herein which can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or any combination thereof can be viewed as being composed of various types of “electrical circuitry.” Consequently, as used herein “electrical circuitry” includes, but is not limited to, electrical circuitry having at least one discrete electrical circuit, electrical circuitry having at least one integrated circuit, electrical circuitry having at least one application specific integrated circuit, electrical circuitry forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program which at least partially carries out processes and/or devices described herein, or a microprocessor configured by a computer program which at least partially carries out processes and/or devices described herein), electrical circuitry forming a memory device (e.g., forms of random access memory), and/or electrical circuitry forming a communications device (e.g., a modem, communications switch, or optical-electrical equipment).
Those skilled in the art will recognize that it is common within the art to describe devices and/or processes in the fashion set forth herein, and thereafter use standard engineering practices to integrate such described devices and/or processes into larger systems. That is, at least a portion of the devices and/or processes described herein can be integrated into a network processing system via a reasonable amount of experimentation.
The foregoing described aspects depict different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functionality.
This application claims priority under 35 USC 119 to U.S. application No. 61/139,446 filed on Dec. 19, 2008, which is presently pending and which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61139446 | Dec 2008 | US |
