400 is a set of lexer and parser rules that define grammar. ANTLR4 optionally enables combining the lexer and parser into one composite grammar file.

FIG. 5 is an analysis method in accordance with some embodiments. At S510, the system may analyze integration flow component attributes. For example, the system may analyze the integration flow of a BPMN2 model for specific attributes related to integration flow steps. For all BPMN2 elements whose attributes or extensionElements has a property key called cmdVariantUri, if its value starts with ctype::Flowstep Variant then it is treated as integration flow step. These integration flow steps may have many attributes, and these attributes constitute guidelines for many integration flow design guideline rules. For example, a: “Manage Large Batch Sizes” rule has attributes to be analyzed for an integration flow step to decide if the integration flow can handle large batch sizes in outbound requests.

At S520, the system may analyze integration flow process attributes. Integration flow process attributes are attributes (extensionElements) defined for the integration process in the BPMN2 model. These attributes may impact the guidelines for some of integration flow design guideline rules. For example, for a “Define Proper Transaction Handling” rule, this might be configured at integration process level. At S530, the system may analyze integration flow collaboration attributes. Integration flow collaboration attributes are attributes (extensionElements) defined for the entire collaboration space in the BPMN2 model. These attributes may impact the guidelines for some of integration flow design guideline rules. For example, for a “Specify Proper Session Handling” rule, this may be configured at collaboration level where multiple integration processes participate in the BPMN2 model.

At S540, the system may analyze occurrence of integration patterns. This analysis may check for the occurrence of specific integration patterns in the integration flow BPMN2 model. For example, as a part of an “Apply Message-Level Security” rule may indicate which verify sign and encrypt integration flow steps are implemented. At S550, the system may analyze product profile Component Meta-Data (“CMD”) and software version incompatibilities. This analysis may check whether the latest version of the component was used in the integration flow development. This check may be required when the IFDG validator service is initialized with the latest version of the product CMD. If the component version that was used is old, the flow may lack enhancements that were later released for improvements of integration flow step.

At S560, the system may analyze scripting code for standard deviations and wrong usage of libraries and functions. This analysis may check if the scripts that were used in the integration flow develop follow some guidelines: were coding standard followed, are any third-party libraries used, usage of certain parsing techniques, security violations (e.g., the logging of sensitive data or accessing secure data), etc. At S570, the system may analyze BPMN2 model semantic deviations (such as identifying orphan nodes with a sequence flow). This analysis may check for defects during integration flow modeling using BPMN2 model using Integrated Development Environment (“IDE”) tools. For example, one of the common mistakes is having an orphan integration flow step without being a participant in the integration process or collaboration. At S580, the system may analyze cloud integration rules. For example, open source CPILint rules automate the governance of integration flows by writing executable, rule-based development guidelines.

FIG. 6 is an integration flow design guidelines validator tool framework 600 according to some embodiments. Here, rules 610 (e.g., rule 1 and rule 2) may be provided to a RuleSet 620. The RuleSet 620 provides a way to characterize the rules 610 by different qualities in a parent/child hierarchy (e.g., qualities associated with optimizing performance, optimizing memory footprint, security, transaction handling, script usage, etc.). These RuleSet 620 attributes may be derived from integration flow design guideline documentation.

The rules 610 provide an implementation for integration flow design guidelines rules as provided in help documentation for guidelines to design enterprise-grade integration flows. The rules 630 may be initialized via rule definition 630. The rule definition 630 provides scope 632 for rule analysis, details of component 634 and component attributes 636 (e.g., BPMN2 elements), integration patterns 638 to look for in the integration flow BPMN model, etc. In this way, the rule definition 630 may provide unique rule-specific configurations, which can help different components of IFDG validator service analyze the integration flow for design guideline rule compliance. According to some embodiments, each design guideline rule has its own rule definition 630 that provides data about what information should be analyzed in the BPMN2 model (e.g., where information may be related to BPMN2 elements and their attributes).

The framework also includes analysis categories 640 (e.g., category 1 and category 2) to help generate rule analysis result based on rule invocation and provide result back to the IFDG validator UI. Here, the rule invocation process may capture many details such as is the rule applicable, if applicable, did the rule compliance check pass, what elements are causing the compliance check failure, etc. The framework also includes rule execution plans 650 (e.g., plan 1 and plan 2) to implement logic to analyze an integration flow BPMN2 model depending on the different analysis categories 640 that the IFDG validator service framework supports. For example, a rule execution plan 650 may implement functionality to parse and analyze a BPMN2 model for rule definition entities as a part of a rule compliancy check analysis.

In some embodiments, an integration flow analysis can be enhanced to visually highlight the pipeline steps which are the source of problems based on design guidelines validator identified BPMN2 elements. This may help an integration flow developer quickly navigate to the BPMN2 that is associated with an enterprise integration pattern and needs some configuration changes. For example, FIG. 7 illustrates guideline deviations 700 in a BPMN2 modeler in accordance with some embodiments. Here, a human-readable integration flow design guideline requirement 710 is analyzed and used to highlight problematic integration flow segments 720 (e.g., in a BPMN viewer). Since we know all of the BPMN2 elements that were involved in the analysis (and have design guideline deviations for various rules), the system can color the corresponding BPMN shapes or diagrams to highlight them. This will help the user identify the integration flow steps and make corrections as per the recommendations.

FIGS. 8A and 8B are a more detailed view of a business technology platform 800 according to some embodiments. An IFDG validator User Interface (“UI”) 810 includes an integration flow upload manager 820 and a user workspace 822. The user workspace 822 may list all of the integration flows that were uploaded into the workspace, any of which can be selected for design guideline rule analysis. Also, uploads can be removed after analysis is completed. A user configuration manager 830 may include configure design guideline rules 832 to customize, sort, or group the integration flow design guidelines rules that a specific user wants to use and maintain for analysis purposes. The user configuration manager 830 may also include configure naming conventions 834 that check if naming conventions for different integration flow steps etc. are being followed. These may change from customer-to-customer and for different business scenarios of integration flows. As a result, a user may want to define custom regular expressions to validate the different integration flow step naming conventions. The end user may easily modify this JSON in the text editor and provide custom versions for different pipeline steps. The user configuration manager 830 may further include configure cloud integration rules 836. For example, CPILint is a third-party rule validation framework that helps users add custom rules for some development specific validations via a command-line tool that automates governance of integration flows.

A communication manager 838 may be responsible for communicating with the IFDG validator service 850 and handle the requests/responses, using responses to build a data model (which can be consumed by different components such as the user workspace 822 or analysis result visualizer 840). The communication manager 838 may also handle report download requests from the end user via the report manager 842 and presentation of results via a report manager 842.

The IFDG validator service 850 includes SAP™ HANA® 860, an Analysis job creator 862, an ANTLR grammar generator and rule expression validator 870, and an IFDG rule engine 880 similar to the corresponding components described in connection with FIG. 3. The IFDG rule engine 880 may interact with a cloud integration service 890 to provide integration with CPILint (an open-source framework to automate governance of integration flows using writing executable, rule-based development guidelines).

FIG. 8B is a more detailed view of the IFDG rule engine 880 including a rule identifier and categorizer 881 that receives a job identifier and user configuration information (e.g., a list of rules that a user wants to run, a naming convention JSON, etc.) along with user context information (e.g., a user identifier, a user email address, and a user name). The rule identifier and categorizer 881 can then fetch the integration flow BPMN2 model and script data from the SAP™ HANA® 860. The rule identifier and categorizer 881 also identifies the set of rules to run from the request input and categorizes them based on analysis categories.

The IFDG rule engine 880 also includes rule execution 882 that interacts with a BPMN2 model analyzer 884, a script analyzer 885, and a cloud integration rules manager 886. Based on data from previous module input, the rule execution 882 may initialize a rule definition configuration specific to rule (e.g., containing details related to scope) and determine the component, attributes, and integration patterns that need to be analyzed. The rule execution 882 may then initialize the rule invocation class with specific input arguments (depending on rule analysis category) assign a rule execution plan to identify integration flow steps that need to be analyzed for deviation from the integration flow design guidelines. During rule invocation, these execution plans get executed and BPMN2 elements may be identified for further analysis either at a process or attributes level. The rule execution 882 then runs the rule, validates the rule execution 882 response, and builds a rule analysis response object. In some embodiments, the rule response is enriched with additional metadata (e.g., severity, rule name, rule analysis results, etc.).

The IFDG rule engine 880 further includes a rule execution planner 883 that chains the rule execution 882 methods for all the rules that the user requested to run and aggregates the result of each rule execution 882. The rule execution planner 883 may also save the aggregated rule execution response to the SAP™ HANA® 860 with user context and return final aggregated rule execution response to IFDG validator UI 810

FIG. 9A is an integration flow design guidelines tool display 900 in accordance with some embodiments. The display 900 includes a list 910 of integration flow files that can be selected for upload and validation. The user selects files in the list 910, selects an “Upload Flow” icon 912 (e.g., via touchscreen or computer mouse pointer 990) to begin the process. The user can then select a “Run IFDG Rules” icon 914 to analyze the uploaded integration flows with respect to all integration flow design guideline rules in a few seconds. The user may also select a “Configure Rules” icon 916, a “Naming Convention” icon 918, and/or an “Integration Rules” icon 920 to customize the system.

The display 900 further includes a list of results 950. The results 950 include RuleSet names associated with a grouping of integration flow design guidelines rules based on different categories as described in public documentation. The results 950 further include a rule name associated with a grouping of integration flow design guidelines rules based on different RuleSets. The results 950 also include an indication of whether each rule as applicable (as decided by a IFDG validator service based on usage of specific enterprise integration patterns or pipeline steps in the integration flow) and an indication of rule compliance attribute (decided by the IFDG validator service based on BPMN2 model analysis for that specific integration flow). In some embodiments, the results 950 also include a severity indicating a priority to fix the problem in the integration flow implementation (e.g., based on performance, transaction handling, scripting, etc.). The results 950 may further include an analysis link that will provide insight into the issues which are being identified in the integration flow during the compliance check scan and provide a recommendation how it can be resolved. The user can also select a “Download Report” icon 952 to receive a PDF or Excel® file summarizing the validation results.

FIG. 9B is another integration flow design guidelines tool display 901 in accordance with some embodiments. In this case, the display 901 includes a guideline deviation highlight icon 902 in the list of results 950. Selection of the icon 902 may result in the system visually highlighting guideline deviations in the BPMN viewer for the analyzed integration flow. Since the system is aware of the BPMN2 elements involved in the analysis (and have design guideline deviations for various rules), it can color or otherwise draw attention to the corresponding BPMN shapes or diagrams. This may help a user identify the applicable integration flow steps and implement corrections as per the recommendations. Such an embodiment may let the user easily locate the relevant integration flow steps even in a complex integration flow with hundreds of steps or BPMN2 elements.

Thus, embodiments may provide an automation solution that checks and validates adherence to many integration flow design guidelines for a provided integration flow (and identify integration flow steps that need to be fixed). Embodiments may also not only identify deviations but also provide recommendations about how to fix the problems and where to fix it (which pipeline steps) in the integration flow BPMN2 model.