CLAIM OF PRIORITY

This application claims priority under 35 USC § 120 to U.S. patent application Ser. No. 14/665,825, filed on Mar. 23, 2015, the entire contents of which are hereby incorporated by reference.

BACKGROUND

The present disclosure relates to application integration modeling in an integration system, particularly for data-intensive application integrations.

Application integration is a process of linking multiple business applications (e.g., supply chain management applications, enterprise resource planning (ERP) systems, customer relationship management (CRM) applications, business intelligence applications, payroll and human resources systems, etc.) together to simplify and automate business processes. An integration system can include a number of logic integration patterns (also referred to as integration logic or integration logic programs) that form an integration process that operate on, for example, messages of applications. For example, messages can be sent and received by integration adapters that provide applications (e.g., business applications) with access to an integration process.

Conventional modeling of message-based integration (e.g., business application integration) scenarios is exclusively control-flow-centric, for example, by defining a control flow including a series of enterprise integration pattern (EIP) Icon Notations, although message-based integration is mainly about message routing and transformations that are based on the data/content of a message. The conventional integration modeling underspecifies the data flow and can be deficient especially for data-intensive application integrations.

SUMMARY

The disclosure generally describes computer-implemented methods, software, and systems for data-centric integration modeling. One computer-implemented method includes receiving, by operation of an integration system, a logic integration program comprising a plurality of logic integration patterns that are defined in a data-centric logic integration language; generating a logical model graph based on the logic integration program, the logical model graph being runtime-independent; converting the logical model graph into a physical model graph, the physical model graph being runtime-specific; and generating logic integration runtime codes executable by the integration system based on the physical model graph.

Other implementations of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of software, firmware, or hardware installed on the system that in operation causes (or causes the system) to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

The foregoing and other implementations can each optionally include one or more of the following features, alone or in combination.

A first aspect, combinable with the general implementation, further comprising defining the logic integration program using the data-centric logic integration language for declarative integration programming.

A second aspect, combinable with any of the previous aspects, wherein defining a logic integration program comprises: analyzing integration logic represented by the logical model graph; and adding integration artifacts.

A third aspect, combinable with any of the previous aspects, wherein the logical model graph comprises one or more annotations defined by the data-centric logic integration language as one or more nodes of the logical model graph.

A fourth aspect, combinable with any of the previous aspects, wherein the logical model graph comprises no cycles.

A fifth third aspect, combinable with any of the previous aspects, wherein converting the logical model graph into the physical model graph comprises: detecting patterns on the logical model graph; and performing a rule-based transformation of the patterns on the logical model graph; and mapping into implementation-specific messaging channels.

A sixth aspect, combinable with any of the previous aspects, further comprising optimizing the logical model graph.

The subject matter described in this specification can be implemented in particular implementations so as to realize one or more of the following advantages. Example techniques for declarative, data-centric integration scenario modeling are provided, which allows for automatic optimization of scenarios by combining optimizations from both data management domain and integration control domain (e.g., data partitioning, parallelization, scatter/gather, splitter/gather). The example modeling is an integration domain-specific language (DSL) grounded on data-centric languages and can be implemented in any relational logic languages, such as PROLOG, DATALOG, or XML- or JSON-based languages. An annotation dialect for integration artifacts (e.g., sender/receiver adapter, aggregate, split) that cannot be automatically derived from the data dependencies (e.g., Abstract Syntax Tree (AST)) can be added to integration rules (e.g., DATALOG rules) to attach integration semantics. The example techniques can semantically extend integration programs and build an AST based on the actual pieces of data, data operations, and (integration-specific) annotations (e.g., as nodes) and their interdependencies (e.g., as edges). The techniques allow declaratively describing “what” shall be the result, instead the usual, imperative “how to get there”, thus making the approach more intuitive, lowering the learning curve, and requiring less technical knowledge. The example techniques allow defining a rule-based (traversal) approach on the data AST that derives basic integration patterns like message transformations, content-based routing, message filters, and inline content enriching. The rule-based techniques allow specifying match/execute conditions that are used to apply optimizations on the graph, such as AST analysis (e.g., unnecessary operations), independent data/operations (e.g., parallelization), and data partitioning. The (optimized) AST can be rewritten to a runtime-near message route graph using graph transformation. The graph can be used to generate integration runtime or intermediate code (e.g., DATALOG Blocks constructs). Apart from some optimizations, the transformations can be bijective, thus allowing for runtime monitoring up to the original language constructs (i.e., linking the actual runtime with the integration syntax/user interface (UI)). When leveraging the runtime feedback, this allows for debugging of integration constructs/programs.

The details of one or more implementations of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

