This specification relates to data processing systems implemented on computers, and, more particularly, to data processing systems providing services in the nature of web services.
Enterprise software systems are generally large and complex. Such systems can require many different components, distributed across many different hardware platforms, possibly in several different geographical locations. Thus, the architecture of a large software application, i.e., what its components are and how they fit together, is an important aspect of its design for a successful implementation.
Web services are one technology for making the functionality of software applications available to other software, including other applications. A web service is a standards-based way of encapsulating the functionality of an application that other applications can locate and access. A service-oriented architecture is a distributed software model within which functionality is defined as independent web services. Within a service-oriented architecture, web services can be used in defined sequences according to business logic to form applications that enable business processes.
This specification describes the foundation layer for a services architecture design for implementing services-based applications having various functionality at the level of an enterprise application.
In its various aspects, the invention can be embodied in systems, methods, and computer program products. For example, a system in one embodiment implements a services architecture design that provides foundation layer functionality for enterprise applications. The design includes service operations, data objects, and process components. Business objects can also be included. Particular embodiments can be replicated and synchronized on multiple computer hardware platforms that are distinct and separate from each other to support a software application deployed in distinct aspects on the separate hardware platforms.
The subject matter described in this specification can be implemented to realize one or more of the following advantages. Effective use is made of process components as units of software reuse, to provide a design that can be implemented reliably in a cost effective way. Effective use is made of deployment units, each of which is deployable on a separate computer hardware platform independent of every other deployment unit, to provide a scalable design. Service interfaces of the process components define a pair-wise interaction between pairs of process components that are in different deployment units in a scalable way.
Details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and in the description below. Further features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.
The elements of the architecture include the business object, the process component, the service operation (or simply, the operation), the service interface, the message, and the deployment unit. The elements can also include process agents and reuse service components. These will be generally described below.
In some implementations, the application software is implemented to be deployed on an application platform that includes a foundation layer that contains all fundamental entities that can be used from multiple deployment units. These entities can be process components, business objects and reuse service components. A reuse service component is a piece of software that is reused in different transactions. A reuse service component is used by its defined interfaces, which can be, e.g., local APIs (Application Programming Interfaces) or service interfaces.
The elements of the architecture can be implemented to realize a software application that implements enterprise application service interfaces. The elements of the architecture are at times described in this specification as being contained or included in other elements; for example, a process component is described as being contained in a deployment unit. It should be understood, however, that such operational inclusion can be realized in a variety of ways and is not limited to a physical inclusion of the entirety of one element in another.
The architectural elements include the business object. A business object is a representation of a type of a uniquely identifiable business entity (an object instance) described by a structural model. Processes operate on business objects.
A business object represents a specific view on some well-defined business content. A business object represents content, and instances of business objects include content, which a typical business user would expect and understand with little explanation. Whether an object as a type or an instance of an object is intended by the term “object” is generally clear from the context, so the distinction will be made explicitly only when necessary. Also, for convenience and brevity, an object instance may be described in this specification as being or including a real world event, activity, item, or the like; however, such description should be understood as stating that the object instance represents (i.e., contains data representing) the respective event, activity, item, or the like. Properly implemented, business objects are implemented free of redundancies.
Business objects are further categorized as business process objects, master data objects, mass data run objects, dependent objects, and transformed objects. A master data object is an object that encapsulates master data (i.e., data that is valid for a period of time). A business process object, which is the kind of business object generally found in a process component, is an object that encapsulates transactional data (i.e., data that is valid for a point in time). A mass data run object is an application object that executes an algorithm for a particular mass data run, and generally has a name that includes “run.” An instance of a mass data run object embodies or contains a particular set of selections and parameters. A mass data run object implements an algorithm that modifies, manages, and/or processes a large amount of data in multiple transactions, possibly but not necessarily with parallel processing. A dependent object is a business object used as a reuse part in another business object. A dependent object represents a concept that cannot stand by itself from a business point of view. Instances of dependent objects only occur in the context of a non-dependent business object. A transformed object is a transformation of multiple business objects for a well-defined purpose. It transforms the structure of multiple business objects into a common structure. A transformed object does not have own persistency.
The architectural elements also include the process component. A process component is a software package that realizes a business process and generally exposes its functionality as services. The functionality includes the ability to perform all or parts of particular kinds of business transactions. A process component contains one or more semantically related business objects. Any business object belongs to no more than one process component.
Process components are modular and context-independent. That they are context-independent means that a process component is not specific to any specific application and is reusable. The process component is the smallest (most granular) element of reuse in the architecture.
The architectural elements also include the operation. An operation belongs to exactly one process component. A process component generally has multiple operations. Operations can be synchronous or asynchronous, corresponding to synchronous or asynchronous process agents, which will be described below. An operation is the smallest, separately-callable function, described by a set of data types used as input, output, and fault parameters, or some combination of them, serving as a signature. For convenience in supporting use of the operations supported by a system implementing elements of the design, such a system can optionally include a repository of service descriptions that includes a standards-based description of each of the supported service operations.
The architectural elements also optionally include the service interface, which may be referred to simply as an interface. An interface is a named group of operations. Each operation belongs to exactly one interface. An interface belongs to exactly one process component. A process component might implement multiple interfaces. In some implementations, an interface will have only inbound or outbound operations, but not a mixture of both. One interface can include both synchronous and asynchronous operations. All operations of the same type (either inbound or outbound) which belong to the same message choreography will preferably belong to the same interface. Thus, generally, all outbound operations to the same other process component are in one interface.
The architectural elements also include the message. Operations transmit and receive messages. Any convenient messaging infrastructure can be used. A message is information conveyed from one process component instance to another, with the expectation that activity will ensue. An operation can use multiple message types for inbound, outbound, or error messages. When two process components are in different deployment units, invocation of an operation of one process component by the other process component is accomplished by an operation on the other process component sending a message to the first process component.
The architectural elements also include the process agent. Process agents do business processing that involves the sending or receiving of messages. Each operation will generally have at least one associated process agent. A process agent can be associated with one or more operations. Process agents can be either inbound or outbound, and either synchronous or asynchronous.
Asynchronous outbound process agents are called after a business object changes, e.g., after a create, update, or delete of a business object instance.
Synchronous outbound process agents are generally triggered directly by a business object.
An outbound process agent will generally perform some processing of the data of the business object instance whose change triggered the agent or caused the agent to be called. An outbound agent triggers subsequent business process steps by sending messages using well-defined outbound services to another process component, which generally will be in another deployment unit, or to an external system. An outbound process agent is linked to the one business object that triggers the agent, but it is sent not to another business object but rather to another process component. Thus, the outbound process agent can be implemented without knowledge of the exact business object design of the recipient process component.
Inbound process agents are called after a message has been received. Inbound process agents are used for the inbound part of a message-based communication. An inbound process agent starts the execution of the business process step requested in a message by creating or updating one or multiple business object instances. An inbound process agent is not the agent of a business object but of its process component. An inbound process agent can act on multiple business objects in a process component.
Synchronous agents are used when a process component requires a more or less immediate response from another process component, and is waiting for that response to continue its work.
Operations and process components are described in this specification in terms of process agents. However, in alternative implementations, process components and operations can be implemented without use of agents using other conventional techniques to perform the functions described in this specification.
The architectural elements also include the deployment unit. A deployment unit includes one or more process components and, optionally, one or more business objects, that are deployed together on a single computer system platform. Conversely, separate deployment units can be deployed on separate physical computing systems. For this reason, a deployment unit boundary defines the limits of an application-defined transaction, i.e., a set of actions that have the ACID properties of atomicity, consistency, isolation, and durability. To make use of database manager facilities, the architecture requires that all operations of such a transaction be performed on one physical database; as a consequence, the processes of such a transaction must be performed by the process components of one instance of one deployment unit.
The process components of one deployment unit interact with those of another deployment unit using messages passed through one or more data communication networks or other suitable communication channels. Thus, a deployment unit deployed on a platform belonging to one business can interact with a deployment unit software entity deployed on a separate platform belonging to a different and unrelated business, allowing for business-to-business communication. More than one instance of a given deployment unit can execute at the same time, on the same computing system or on separate physical computing systems. This arrangement allows the functionality offered by a deployment unit to be scaled to meet demand by creating as many instances as needed.
Since interaction between deployment units is through service operations, a deployment unit can be replaced by other another deployment unit as long as the new deployment unit supports the operations depended upon by other deployment units. Thus, while deployment units can depend on the external interfaces of process components in other deployment units, deployment units are not dependent on process component interactions (i.e., interactions between process components involving their respective business objects, operations, interfaces, and messages) within other deployment units. Similarly, process components that interact with other process components or external systems only through messages, e.g., as sent and received by operations, can also be replaced as long as the replacement supports the operations of the original.
Interactions between process components that occur only within a deployment unit are not constrained to using service operations. These can be implemented in any convenient fashion.
In contrast to a deployment unit, the foundation layer does not define a limit for application-defined transactions. Deployment units communicate directly with entities in the foundation layer, which communication is typically not message based. The foundation layer is active in every system instance on which the application is deployed. Business objects in the foundation layer are generally master data objects. In addition, the foundation layer may include some business process objects that are used by multiple deployment units. Master data objects and business process objects that should be specific to a deployment unit should be assigned to their respective deployment unit.
The Business Partner Data Management process component 101 (
The Company Tax Exemption Certificate master data object 141 represents a certificate issued by a company to a supplier claiming exemption from product tax for purchases. The Business Partner master data object 142 represents a person, organization or group of persons or organizations in which a company has a business interest. The Employee master data object 143 represents a person who contributes or has contributed to the creation of goods or services for a company, and can describe “internal” employees and/or “external” employees. Unlike externals, an internal employee is in a position of subordination to another's authority. The Clearing House master data object 144 represents an organization that provides services for the settlement of payment card payments, such as the authorization of payments. The Party transformed object 145 represents a person, an organization, an organizational center, or a group of persons, in which a company has a business interest. The Payment Card master data object 146 represents an issued identification card that can enable the card holder to achieve cashless payments for invoices to an accepting company (e.g., a merchant). The Customer master data object 147 represents a business partner with whom a business relationship exists. The Supplier master data object 148 represents a business partner who provides materials and/or services. The Tax Authority master data object 149 represents a business partner for value added tax declaration. The House Bank master data object 150 represents a business partner providing services for a company, such as account management or lock box. The Communication Arrangement master data object 151 represents an arrangement between the system owner and a business partner, containing the communication settings for XML messaging, file-based communication and form-based communication via output channels like print, email and fax. The Sales Arrangement master data object 152 represents an arrangement that is made by a sales unit for a customer, and is used for sales transactions. The arrangement can include, for example, terms of payment, invoice currency, and incoterms. The arrangement can optionally constitute a contract with a customer. The Procurement Arrangement master data object 153 represents an arrangement used to control procurement transactions, which can be established between a supplier and a purchasing unit, but also for one supplier across all purchasing units. The Supplier Product Category Life Cycle master data object 154 represents a supplier life cycle that contains information about the status of supplier development and the product category delivered by that supplier. The Payment Agreement master data object 155 represents the agreement between a company and a business partner concerning the handling of payments. The Company Tax Exemption Certificate master data object 156 represents a certificate issued by a company to a supplier claiming exemption from product tax for purchases. The Customer Tax Exemption Certificate 157 represents a certificate sent by a customer to a company claiming exemption from tax on sales/purchases.
The Organizational Management process component 102 (
The Product Data Maintenance process component 103 (
The Material Procurement Process Control master data object 175 represents a process-driven view that contains information about a material that is used in procurement-relevant processes. The Material Supply Planning Process Control Template master data object 176 represents a template that simplifies the maintenance of material master data used to control procurement planning Planning is performed at supply planning area level (including specifications for lot-size planning, requirement consumption, in-house production. The Material Supply Planning Process Control master data object 177 represents a process-driven view that contains information about a material that uses the material in supply planning processes. The Service Product Financials Process Control master data object 178 represents a process-driven view that contains information about a service that is used in financial processes. The Material Inventory Process Control Template master data object 179 represents a template that simplifies the maintenance of material master data used to control several logistic processes. The collection includes the inventory management unit of measure and the unit of measure in which a material is serialized. The Service Product Procurement Process Control master data object 180 represents a process-driven view that contains information about a service that is used in procurement-relevant processes. The Material Procurement Process Control Template master data object 181 represents a template that simplifies the maintenance of material master data used in procurement-relevant processes. The Material Financials Process Control Template master data object 182 represents a template that simplifies the maintenance of material master data used to process in Financials (including the inventory valuation). The Service Product Procurement Process Control Template master data object 183 represents a template that simplifies the maintenance of Service Product master data used in procurement-relevant processes. The Warranty master data object 184 represents a guarantee to vouch for defects or faults in the product purchased that is valid for a specific period of time. The type and scope of the services covered, such as repairing a defect for free or taking the product back, are defined in the warranty. The Individual Material Service Process Control master data object 185 represents a process-driven view that contains information about an individual material in customer service processes. The Material Sales Process Control Template master data object 186 represents a template that simplifies the maintenance of material master data used to control presales, sales, and customer service processes. The Individual Material master data object 187 represents a tangible product that occurs only once in the real world and is therefore uniquely identifiable. The Material Financials Process Control master data object 188 represents a process-driven view that contains information about a material that is used in financial processes. The Service Product Financials Process Control Template master data object 189 represents a template that simplifies that simplifies the maintenance of Service Product master data used in processes in Financials (including the inventory valuation). The Material Availability Confirmation Process Control master data object 190 represents a process-driven view that contains information about a material that is used in availability confirmation processes. The Warranty Service Process Control master data object 191 represents a process-driven view that contains information about a warranty that is used in customer service processes. The Material Sales Process Control master data object 192 represents a process-driven view that contains information about a material that is used in presales, sales, and customer service processes. The Service Product Template master data object 193 represents a template that contains service product data relevant for presales, sales, and financials processes. The Material Template master data object 194 represents a template that contains material data relevant for presales, sales, financials, supply planning, and availability confirmation processes. The Material master data object 195 represents a tangible product, such as a sellable article, packaging, auxiliary material, and expendable supplies, that can be created and then represents a business value. In general, a material can be traded, consumed, or produced. The Service Product Sales Process Control Template master data object 196 represents a template that simplifies the maintenance of service product master data used to control presales, sales, and customer service processes. The Material Availability Confirmation Process Control Template master data object 197 represents a template that simplifies the maintenance of material master data used to execute the availability check. The Service Product master data object 198 represents an intangible product that describes the provision of a service. A service is provided at the time of its use. The Service Product Sales Process Control master data object 199 represents a process-driven view that contains information about a service that used in presales, sales, and customer service processes. The Identified Stock master data object 101A represents a subset of a material that shares a set of common characteristics, is logistically handled separately from other subsets of the same material and is uniquely identified. The Material Inventory Process Control master data object 102A represents a process-driven view that contains information about a material that is used in logistics processes.
The Resource Data Management process component 104 (
The Location Data Management process component 105 (
The Logistics Area and Storage Management process component 106 (
The Human Capital Master Data Management process component 107 (
The Business Document Flow Processing process component 108 (
The Document Management process component 109 (
The Production Model Management process component 110 (
The Site Logistics Model Management process component 111 (
The Activity Management process component 112 (
The Source of Supply Determination process component 113 (
The Software Problem Reporting process component 114 (
The Installed Base Data Management process component 115 (
The Price Master Data Management process component 116 (
The Identity Management process component 117 (
The Data Flow Verification process component 118 (
The Engineering Change Processing process component 119 (
The Financial Market Data Management process component 120 (
The Logistic Unit Data Management process component 121 incorporates all master data necessary when handling or using logistic units, including grouping and packing instructions. The Logistic Unit Data Management process component 121 includes a Logistic Unit master data object 158A, a Logistic Unit Usage master data object 159A, and a Packing Bill of Material master data object 160A. The Logistic Unit master data object 158A represents an item established for logistics operations, such as storage, movement, and packing. The Logistic Unit master data object 158A can represent all physical units handled in the same manner during logistic operations, whether they are packed or unpacked goods. The Logistic Unit Usage master data object 159A represents a logistics purpose for which Logistic Units are grouped. The Logistic Unit Usage can represent a process or an activity, such as conveying, packing, or storing. The Packing Bill of Material master data object 160A represents a complete and structured list of components that define the packing structure of logistic units.
The Input and Output Management process component 122 covers form-based input and output as well as structured file import and export. For example, form-based input and output can include collaboration by means of interactive forms. Output management can handle front-end and back-end output. Form-based output can have different channels such as print, e-mail and fax. The 122 Input and Output Management process component includes: a Controlled Output Request dependent object 161A, an Output Request technical object 162A, an Output Task technical object 163A, an Output Error technical object 164A, a File Input Control technical object 165A, an Output Control dependent object 166A, and an Output Determination Rule master data object 167A. The Controlled Output Request dependent object 161A represents a request to send documents related to the hosting business object to a specified output channel. It can support form-based back-end output of the hosting business object and stores the output history. The Output Request technical object 162A represents a request to send a document to a specified output channel. The Output Task technical object 163A represents a task that outputs data to an output channel. The Output Error technical object 164A represents an error that occurred during the processing of an output request. The File Input Control technical object 165A represents the initiation and control of the processing of inbound files by the adapter service. The Output Control dependent object 166A represents a set of settings for form-based output via channels like print, email and fax. It controls master-data dependent output. The Output Determination Rule master data object 167A represents a rule defining which set of output parameters to use during output. An Engineering Change Case business process object 168A is also included in the Foundation layer in
As shown in
The Payment Explanation dependent object 169A represents the reason(s) for a payment, typically with reference to one or more business documents such as contracts, invoices, credit memos, or sales orders. The Accounting Coding Block Distribution dependent object 146A represents the distribution of coding blocks to enterprise resources changes, such as expenses or material movements. A coding block can be a set of accounting objects to which an enterprise resource change is assigned. The resource change can ultimately be valued in Accounting. For example, an employee can record eight hours of his working time (the resource change), allocated six hours to a project and two hours to his cost center, thereby distributing his total time to two coding blocks (the first containing the project, and the second containing the cost center). The Financial Audit Trail Documentation dependent object 170A represents the uniform documentation of the changes to receivables and payables and financial transactions linked to a business transaction for audit purposes. The Address dependent object 148A represents the data that describes the addressee, postal address and communication connections. The address can be used both in master data objects (e.g., customer) and business process objects (e.g., sales order). The Storage Control dependent object 171A represents the specification of inventory items' constraints and inventory items' rules applied in a storage location (such as logistics area or resource), as well as requirements for actions (such as replenishment and cleanup). The Payment Control dependent object 172A represents an agreement between a company and a business partner on processing payments for an individual business transaction. The Market Segment dependent object 173A represents a sector of the overall market that is characterized by a specific constellation of supply and demand and that exhibits specific customer and product characteristics as well as characteristics for regional and organizational classification (e.g., sweets that are sold within the region Europe). The Cash Discount Terms dependent object 174A represents the modalities agreed upon between business partners for the payment of goods delivered or services provided. These modalities can consist of incremental payment periods and the cash discounts that are allowed when payment is made within one of these periods. Cash discount terms can be used to define terms of payment, for example, for a purchase order or invoice issue for control the common transactional buffer for Folder dependent object 175A represents a collection of planning data. The Go Live Checklist transformed object 166A represents a check list which guides the customer through the activities which are mandatory or critical before going live with the customer's system landscape. During business setup or during continuous change, the customer can typically perform several activities in order to adjust the system to specific business needs.
As shown in
The Cross Product Catalog Search technical object 177A represents the condition used for and the result of a search across product catalogs. The Transactional Planning Data Buffer Control technical object 178A represents a means to control the common transactional buffer for planning data. The Process Integration Inbound Error technical object 179A represents an error that occurred during the inbound message processing. It contains information about the incorrectly exchanged message like the message payload and log messages of the inbound processing. The Task technical object 180A represents a task is a request to perform an action that can be executed in order to achieve a business or technical objective. The task results from changes within a business or technical process. The Catalog Access Result technical object 181A represents a result from a catalog that contains user-requested data, which is transferred from a catalog to a business document. The Catalog Access Specification technical object 182A represents a specification to access a web-based catalog that contains a uniform identifier including parameters and control settings.
As shown in
As shown in
The Pricing Engine process component 124 handles the processing of price and tax calculation. The Pricing Engine process component 124 includes a Price and Tax Calculation dependent object 188A, a Price Calculation dependent object 189A, a Tax Calculation dependent object 190A, and a Price Specification dependent object 191A. The Price and Tax Calculation represents the summary of the determined price and tax components for a business case. The Price Calculation dependent object 189A represents the summary of the determined price components for a business case. The Tax Calculation dependent object 190A represents the summarization of the determined and calculated tax elements of a business case. The Price Specification dependent object 191A represents a specification of a price, a discount, or a surcharge for sales, service, and purchasing. The specification is defined for a combination of properties and is valid for a specific period.
As shown in
The Product Property Management process component 126 handles the management of product properties along with their valuations. The Product Property Management process component 126 includes a Product Property List master data object 196A, Product Property Valuation List dependent object 197A, a Product Category Hierarchy master data object 198A, a Product Property Library master data object 199A, and a Product Property Type System dependent object 101B. The Product Property List master data object 196A represents a list of properties from product property libraries that are adjusted to suit one or more products. Attributes of the properties can be added or changed in the list. The Product Property Valuation List dependent object 197A represents a list of product properties of an object with their valuations. The properties and valuations are based on a product property list or product property library. The Product Category Hierarchy master data object 198A represents a hierarchical arrangement of product categories according to objective business aspects. Subordinate product categories represent a semantic refinement of the respective higher-level product category. The Product Property Library master data object 199A represents a library of product properties that can be reused to further describe instances or groups of business objects in specific application areas. The Product Property Type System dependent object 101B represents a consistent system of product properties, along with their definitions and underlying property data types.
As shown in
The Application Log Administration process component 134 handles the administration of application logs. The Application Log Administration process component 134 includes an Application Log technical object 102B that represents a collection of textual information automatically created by the application that describes the activities of a business object. This also includes relevant information about the environment and references to the business object nodes that are involved in the creation of the information.
The Change Document Management process component 135 handles the management of changed documents. The Change Document Management process component 135 includes the Change Document business process object 103B that represents a record of changes made to a object instance. It specifies the identity of the user responsible for the change and the change date and time.
The Inspection Master Data Management process component 136 handles the management of inspection-relevant master data, such as inspection rules and sample-drawing procedures, as well as the definition of quality-relevant catalogs. The Inspection Master Data Management process component 136 includes a Quality Issue Category Catalog 104B, a Sample Drawing Procedure 105B, and an Inspection Rule master data object 106B. The Quality Issue Category Catalog master data object 104B represents a structured catalog of categories that classifies quality-related issues for a particular quality aspect. The Sample Drawing Procedure master data object 105B represents a procedure that defines how samples are to be taken. It contains data for the sample-drawing frequency, sample size, and sample quantity. The Inspection Rule master data object 106B represents a rule that contains the specifications for an inspection. The inspection is used to check whether an object or procedure meets predefined requirements.
The Records and Case Management 138 handles the structuring of business folders. The Records and Case Management 138, includes a Business Folder dependent object 107B and a Business Folder Structure Definition master data object 108B. The Business Folder dependent object 107B represents a folder for collecting and organizing information relating to a business subject according to customer needs. The Business Folder Structure Definition master data object 108B represents a definition of the internal structure and constraints of business folders.
The Product Engineering Foundation process component 137 handles the engineering of product designs. The Product Engineering Foundation process component 137 includes the Product Design business object 109B.
The Key Performance Indicator Management process component 139 handles the management of key performance indicators of a company along with their evaluations. It comprises the services to identify, define, and evaluate key performance indicators of a company for management purposes. The Key Performance Indicator Management process component 139 includes a Key Performance Indicator Evaluation business process object 110B and a Key Performance Indicator business process object 111B.
The Key Performance Indicator Evaluation business process object 110B represents a user-specific, time-dependent, and parameter-based evaluation of a key performance indicator that results in a value. The key performance indicator value is usually assessed against a reference value based on a rule. The Key Performance Indicator business process object 111B represents a quantifiable business performance factor.
As shown in
The Business Rules Management process component 127 includes the Business Rule Definition technical object 112B, the Business Rule Expression technical object 113B, and the Business Rule Parameter Definition technical object 114B. The Business Rule Definition technical object 112B represents a business rule comprising the name and the signature. It describes the operations, definitions, and constraints that apply to an organization in achieving its goals. The Business Rule Expression technical object 113B represents an expression that specifies the business logic of a business rule in a formal way. Business Rule Expressions may be simple such as a constant, case or range or complex such as a decision tree, a decision table or formula. Business Rule Expressions may be nested. The Business Rule Parameter Definition technical object 114B represents the definition of a formal parameter that can be used as an input or output parameter in one or more business rule definitions and in one or more business rule expressions.
The Accounting Coding Block Distribution Processing process component 128 includes an Accounting Coding Block Distribution dependent object that represents the Distribution of Coding Blocks to enterprise resources changes, such as expenses or material movements. A Coding Block is a set of accounting objects to which an enterprise resource change is assigned. The resource change is ultimately valued in Accounting.
The Business process component 129 includes a Go Live Checklist transformed object 116B that represents a list of business options for a business system's customer/prospect to check or further maintain in order to adjust the business system to their specific business needs. Until all activities in Go Live checklist are closed, the customer/prospect's business system can not go live. Each business option in Go Live Checklist is a group of predefined content sets or a manual activity which describes what needs to be done by documentation. The Go Live Checklist transformed object 116B offers the capability for system's customer/prospect to check and further maintain these content sets.
The Number Range process component 130 includes a Number Range technical object 117B that represents a range of numbers that are delimited by an upper and lower boundary, and generated in a consecutive order.
The Date and Time process component 131 includes an Operating Hours dependent object 118B that represents a generic description of time periods based on a recurrence pattern, during which operations are performed.
The Payment Authorization process component 132 includes a Payment Card Payment Authorization technical object 119B that represents an authorization for a payment made using a payment card. It contains payment information including a description of the goods/services purchased, the authorization request, and the result of the authorization request based on the response from the clearing house.
The Logistics Shift process component 133 includes a Logistics Break Program master data object 120B that represents a set of breaks in supply chain processes such as production, warehousing and transportation that are either scheduled at an absolute time of the day or scheduled relative to the start time of a shift; a Logistic Shift master data object 121B that represents a period of working time (called shift) in supply chain processes such as production, warehousing, and transportation that can be interrupted by break; and a Logistics Shift Program master data object 122B that represents a set of shifts, organized as a generic program, in supply chain processes such as production, warehousing and transportation that span over a period of time.
As shown in
As shown in
An interaction may begin when a software problem report is to be changed. The Support Request Processing process component 302 can send a request for changing a software problem report, based on a confirmation coming from a service desk, to the Software Problem Reporting process component 114. The request is received as a message by a Change Software Problem Report operation 304. The operation 304 is included in a Software Problem Reporting In interface 306. The operation 304 initiates a Change Software Problem Report based on Confirmation asynchronous outbound process agent 308 to create or update the Software Problem Report technical object 145A.
The Support Request Processing process component 302 can send a request for changing a software problem report, based on provider information coming from a service desk, to the Software Problem Reporting process component 114. The request is received as a message by a Change Software Problem Report Based on Provider operation 310. The operation 310 is included in an External Requesting In interface 312. The operation 310 initiates a Change Software Problem Report based on Provider Information asynchronous outbound process agent 314 to create or update the Software Problem Report technical object 145A.
An update in the Software Problem Report technical object 145A calls a Request Support from Software Problem Report to Support Request Processing asynchronous outbound process agent 316 to invoke a Request Support operation 318. The operation 318 requests a creation or modification of a support request document in a service desk. For example, such a request can be sent to the Support Request Processing process component 302. The operation 318 is included in a Software Problem Reporting Out interface 320.
An update in the Software Problem Report technical object 145A calls a Request Service from Software Problem Report to Service Request Processing asynchronous outbound process agent 322 to invoke a Request Service operation 324. The operation 324 requests a creation or modification of a service request document in a service desk. For example, such a request can be sent to a Service Request Processing at Provider component 326. The Service Request Processing at Provider component may include logging and resolving of service requests concerning issues that customers have, for example, with regard to products. The operation 324 is included in a External Requesting Out interface 328.
As shown in
As shown in
An interaction can begin with an update to the Operating Hours business object 118B (not shown). The update may invoke a Move Time Point operation 502, a Check if Time Point is Active operation 504, a Get Next Time Active Time Point operation 506, or a Calculation Duration Between Time Points operation 508. The operations 502-508 are included in a Calendar-Based Calculation In interface 510. If one or more of the operations 502-508 are invoked, a Calendar-Based Calculation synchronous inbound process agent 512 can be used to update a business object or process component.
An update in the File Input Control business object 165A calls a Notify of File Input to Adapter Service Outbound process agent 602 to invoke a Notify of File Input operation 604. The operation 604 notifies Input and Output Management about a file, which has to be processed. For example, such an update can be sent to the Input and Output Management process component 122. The operation 604 is included in a File Input Out interface 606.
An update in the Payment Card Payment Authorization business object 119B calls a Payment Authorization synchronous inbound process agent 704 to invoke a Request Payment Authorization operation 706. The operation 706 requests a clearing house for authorization of a payment made by a payment card. For example, the operation 706 may request a clearing house for authorization to the external Settlement Processing at Clearing House process component 702. The Request Payment Authorization operation 706 is included in a Payment Authorizing Requesting Out interface 708.
The product property management process component 126 handles the management of product properties along with their valuations.
As shown in
If the Replicate Product Category Hierarchy operation 804 is invoked, a Replicate Product Category Hierarchy inbound process agent 810 can provide an update to the Product Category Hierarchy business object 198A. If the Synchronous Replicate Product Category Hierarchy operation 806 is invoked, a synchronous Replicate Product Category Hierarchy inbound process agent 812 can provide an update to the Product Category Hierarchy business object 198A.
The interactions can be invoked by an update to an update in a Data Migration System process component 802. The Data Migration System process component 802 can invoke a Replicate Material operation 1002. The Replicate Material operation 1002 creates or updates material master data in a target system using material master data form a source system or file. The operation 1002 is included in a Material Replication In interface. The operation 1002 uses a Replicate Material inbound process agent 1006 to update the Material business object 195, the Material Inventory Process Control business object 102A, the Material Availability Confirmation Process Control business object 190, the Material Sales Process Control business object 192, the Material Financials Process Control business object 188, the Material Supply Planning Process Control business object 177, or the Material Procurement Process Control business object 175.
The Data Migration System process component 802 can also invoke a synchronous Replicate Material operation 1008 in the Material Replication In interface 1004. The synchronous Replicate Material operation 1008 uses a Replicate Material synchronous inbound process agent 1010 to update the Material business object 195, the Material Inventory Process Control business object 102A, the Material Availability Confirmation Process Control business object 190, the Material Sales Process Control business object 192, the Material Financials Process Control business object 188, the Material Supply Planning Process Control business object 177, or the Material Procurement Process Control business object 175.
The Data Migration System process component 802 can also invoke a Replicate Service Product operation 1012. The operation 1012 provides a process agent that migrates or replicates service product master data from a source system or file to a target system. The operation 1012 is included in a Service Product Replication In interface 1014. The Replicate Service Product operation 1012 uses a Replicate Service Product inbound process agent 1016 to update the Service Product business object 198, the Service Product Financials Process Control business object 199, the Service Product Procurement Process Control business object 180, or the Service Product Sales Process Control business object 199.
The Data Migration System process component 802 can also invoke a synchronous Replicate Service Product operation 1018. The operation 1018 uses a process agent that migrates or replicates service product master data from a source system or file to a target system. The operation 1018 is included in the Service Product Replication In interface 1014. The synchronous Replicate Service Product operation 1018 uses a Replicate Service Product synchronous inbound process agent 1020 to update the Service Product business object 198, the Service Product Financials Process Control business object 199, the Service Product Procurement Process Control business object 180, or the Service Product Sales Process Control business object 199.
As shown in
The Data Migration System process component 802 can also invoke a Replicate Warranty operation 1028 included in a Warranty Replication In interface 1030. The operation 1028 uses a Replicate Warranty inbound process agent 1032 to update the Warranty business object 184 or the Warranty Service Process Control business object 191.
The Data Migration System process component 802 can also invoke a Replicate Identified Stock operation 1034 included in an Identified Stock Replication In interface 1036. The operation 1034 uses a Replicate Identity inbound process agent 1038 to update the Identified Stock business object 101A.
The Business Partner operation 142 uses a Notify of Contact outbound process agent 1126 to invoke a Notify of Contact and Account Maintenance operation 1128 or a Notify of Contact and Account Cancellation operation 1130. The operations 1128 and 1130 are included in a Contact Notification Out interface 1132. The operation 1128 updates the Standard Based Groupware process component 410 and the Duet process component 1134.
The Data Migration System process component 802 invokes a Replicate Business Partner operation 1136 or a Cancel Contact and Account operation 1138. The operations 1136 and 1138 are included in a Business Partner Replication In interface 1140. The operation 1136 uses a Replicate Business Partner inbound process agent 1142 to update the Business Partner business object 142. The operation 1138 uses a Cancel Contact synchronous inbound process agent 1144 to update the Business Partner business object 142.
As shown in
The Data Migration System process component 802 can also invoke a Replicate Customer operation 1156 or a Synchronous Replication Customer operation 1158. The operations 1156 and 1158 are included in an Customer Replication In interface 1160. The operation 1156 uses a Replicate Customer synchronous inbound process agent 1162 to update the Customer business object 147, the Sales Arrangement business object 152, or the Payment Agreement business object 155. The operation 1158 uses a Replicate Customer inbound process agent 1164 to update the Customer business object 147, the Sales Arrangement business object 152, or the Payment Agreement business object 155.
The Data Migration System process component 802 can also invoke a Replicate Supplier operation 1166 or a Synchronous Replication Supplier operation 1168. The operations 1166 and 1168 are included in a Supplier Replication In interface 1170. The operation 1166 uses a Replicate Supplier synchronous inbound process agent 1172 to update the Supplier business object 148 or the Procurement Arrangement business object 153. The operation 1168 uses a Replicate Supplier inbound process agent 1174 to update the Supplier business object 148 or the Procurement Arrangement business object 153.
In some implementations, the Data Migration System process component 101 can provide updates to the Party business object 145, the Customer Tax Exemption business object 156, the Clearing House business object 144, the Tax Authority business object 149, the House Bank business object 150, the Company Tax Arrangement business object 141, and the Payment Card 146.
If the Business document Flow business object 120A receives an update, the business object 120A uses a synchronous Business Document Flow Processing to Business Document Flow inbound process agent 1808 to invoke a Query Related Business Document operation 1810. The operation 1810 can query a business document related to a given business document. The operation 1810 is included in a Query Business Document Flow Out interface 1812.
The subject matter described in this specification and all of the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more computer programs tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
The subject matter described in this specification can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
While this specification contains many specific implementation details, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as illustrating preferred embodiments of the invention. Certain features that are described in this specification in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be provided in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
The subject matter has been described in terms of particular variations, but other variations can be implemented and are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.