Systems and methods for monitoring and controlling business level service level agreements

The present invention relates to systems and methods for monitoring and controlling business level SLA (Service Level Agreements), specifically using probe points, KPIs (Key Performance Indicators), and business commitments. For systems and methods that monitor and control business-level SLAs. The present invention further relates to an XML (extensible Markup Language) -based specification called BPCL (Business Process Commitment Language) used to describe business commitments. The BPCL specification is used by business process management (BPM) systems to configure, monitor, and control business processes based on business commitments. Business Commitment and BPCL provide a path to model-based management of dynamic e-business solutions.

Due to innovations in network computing technology and network computing applications, many companies, shops, and organizations are now e-in global telecommunications networks such as the WWW (World Wide Web) and the Internet. Providing business services. Such services are typically provided through the website of an entity. However, most organizations do not have the IT professionals needed to maintain their own websites or to maintain such websites in a cost-effective manner. Moreover, with the rapid advances in dynamic e-business technology, organizations are no longer content with isolated e-business applications and bear the burden of application integration. Company customers prefer industry solutions that are customized and ready to use for their needs. As a result, many organizations have provided IBM Global with their IT services, including the management of secure websites. It outsources to IT service providers, such as Services, who are expected to deliver domain-specific e-business solutions in time and at low cost.

Various systems and methods have been developed or proposed to provide SLM (Service Level Management). SLM is an organized and proactive method and procedure used to ensure that the appropriate level of service is delivered to a service requester. The basis of SLM is a service level agreement (SLA). An SLA is a contract between a service requester and a service provider that specifies the minimum acceptable level of service. Such SLAs can include, for example, quality of service (QoS) and security requirements. The SLM system is an important tool for managing the two-party relationship between a service provider and a service requester.

The vast majority of traditional contract or service level management tools focus individually on external parties (eg, accounts) and therefore lack a global view. For example, the proposed WSLA (Web Service Level Agreement) and tpaML (Trading Partner Agreement Markup Language) specifications of International Business Machines Corporation address the issue of managing external relationships. However, the focus of such specifications is on individual one-to-one relationships and does not provide a solution for managing one-to-many relationships that take into account, for example, interdependencies between the parties.

In addition, there are other standards or specifications proposed to address various aspects of business process management. These will be briefly described below.

ebXML (electronic business XML initiative) BPSS (Business Process Specification Schema) provides a standard framework by which business systems can be configured to support the execution of business collaborations consisting of business transactions. BPSS supports business transaction specifications and business transaction choreography for business collaboration. Each business transaction can be performed using one of many available standard patterns from ebXML. These patterns determine the actual exchange of business documents and business signals between partners to achieve the required e-commerce.

The Business Process Management Initiative's BPML (Business Process Modeling Language) is a metalanguage for modeling business processes. BPML provides an abstract execution model of collaborative transactional business processes based on the concept of transactional finite state machines. BPML considers an e-business process to consist of a common public interface and as many private implementations as process participants. This allows the public interface of a BPML process to be described as an ebXML business process or RosettaNet Partner Interface Process that is independent of the private implementation.

XPDL (XML-based Process Definition Language) of WfMC (Workflow Management Coalition) is an XML-based language for defining business processes. One of the key elements of XPDL is its extensibility to handle information used by various tools. This is because XPDL may not be able to support all the additional information requirements of all tools. One of the most important elements of XPDL is a comprehensive configuration that supports vendor-specific attributes for use in common expressions.

BPEL4WS allows companies to describe business processes involving multiple web services and standardize message exchanges internally and between partners. In BPEL4WS, business processes can be described in two forms. A viable business process models the actual behavior of a participant in a business interaction. In contrast, business protocols use process descriptions that specify mutually visible message exchange behavior for each of the parties participating in the protocol, without revealing their internal behavior. The process description of a business protocol is called an abstract process. BPEL4WS provides a formal language for business processes and business interaction protocols. By doing so, BPEL4WS makes it possible to extend the web service interaction model and support business transactions. BPEL4WS defines an interoperable integration model that facilitates the extension of automated process integration both within the enterprise and in the inter-industry space.

BOpS (Business Operational Specification) defines a notation that specifies an operation view of a business. This notation is called the Business Operational Specification (BOpS) and is represented as an XML Schema definition. A layered view of business system modeling is used. In this view, the business system consists of three layers: strategy, planning, and execution. BOpS addresses the modeling of the planning layer of a business system. By doing so, BOpS bridges the gap between strategy and execution, enables automated generation of execution models, and facilitates execution tracking for strategies.

The languages mentioned above mainly deal with the definition and execution modes of business processes. However, these specifications do not provide a mechanism for monitoring and controlling business-level SLAs and relationships between parties.

<p> An object of the present invention is to provide a system and method for monitoring and controlling a business level SLA (Service Level Agreement) through probe points, KPIs (Key Performance Indicators), and business commitments. is there.</p>

<p> The present invention relates to systems and methods that provide e-business process management. Systems and methods according to the invention that provide e-business process management provide a mechanism for monitoring and controlling business level SLAs using probe points, KPIs (Key Performance Indicators), and business commitments. It is preferable to use it. The BPCL (Business Process Commitment Language) according to embodiments of the present invention is used to declaratively model relationships between external and internal parties and to specify business commitments. BPCL can be used by business process management (BPM) systems to configure, monitor and control business processes based on business commitments.</p><p> In one embodiment of the invention, a model that provides business process management, a business between a plurality of entities associated with a dynamic business process, including external and internal parties associated with the business process. A model described using a business commitment specification that describes relationships globally is described. This model is used to monitor and control business level agreements (SLAs) based on specified business commitments between entities. For example, business commitments are defined using KPIs (Key Performance Indicators), and KPIs are defined using probe points. Business commitments are preferably written using XML (eXtensible Markup Language) syntax.</p><p> In another embodiment of the invention, a system that provides business process management has a build-time component that generates a document that describes the business relationships between multiple entities involved in a dynamic business process. Includes run-time components that handle document specifications to provide business-level SLA management for business processes. Build-time components include development tools that create BPCL documents that specify relationships between probe points, KPIs, and business commitments, and run-time components use business-level SLAs that specify BPCL documents. It is preferable to include components to monitor and control. In one embodiment, the development tool includes an Eclipse-based visual development tool that displays the hierarchical relationships between probe points, KPIs, and business commitments in a BPCL document.</p><p> In another embodiment, the run-time component includes a BPCL configurator module that allows dynamic changes made to the BPCL document and automatic propagation of changes to the run-time component. Run-time components use actuators that send generic notifications or call management directives that can change the execution of business processes, KPI calculators that determine KPI values, and KPI values to evaluate the logical conditions of business commitments. It includes a conditional evaluator and an evaluation trigger that determines the trigger that calls the conditional evaluator. Triggers can be alarm-based or event-based, and alarm-based trigger instructions are provided by the BPCL configurator when reading a BPCL document.</p><p> In another embodiment of the invention, the dependencies between probe points, KPIs, and business commitments are automatically detected to determine the KPIs and business commitments affected by the unavailable probe points. A mechanism is provided.</p><p> In another embodiment of the invention, a method of managing a business process involves performing a business process that includes an integrated set of applications that allow interaction between multiple entities, and said entities. A step in managing the execution of a business process using a business commitment specification that describes one or more business commitments between, a business commitment is defined using a KPI, and the KPI is Includes steps, defined using probe points.</p><p> In another embodiment, the step of managing the execution of the business process is to monitor the probe points associated with the business process and to determine the value of the KPI when the probe points associated with the KPI are activated. It includes a determination step and an evaluation of the business commitment associated with the KPI based on the determined value of the KPI to determine if it violates the business commitment. The value of a KPI can be determined, for example, by calling a function to determine the value of the KPI based on the value of at least one other KPI, or based on the value extracted from the probe point. .. The process of evaluating a business commitment involves using KPI values to evaluate the conditions specified by the business commitment. If it is determined that the business commitment is violated based on the evaluation result, the action can be taken. The steps to initiate an action include providing a violation notification to the entity associated with the business commitment or invoking a management directive to change the execution of the business process.</p><p> The above and other embodiments, features, features, and benefits of the present invention will be explained or will become apparent in the following detailed description of preferred embodiments that should be read with the accompanying drawings.</p>

The present invention relates to systems and methods that provide e-business process management. Systems and methods according to the invention that provide e-business process management provide a mechanism for monitoring and controlling business level SLAs using probe points, KPIs (Key Performance Indicators), and business commitments. It is preferable to use it. The BPCL (Business Process Commitment Language) according to embodiments of the present invention is used to declaratively model relationships between external and internal parties and to specify business commitments. BPCL can be used by business process management (BPM) systems to configure, monitor and control business processes based on business commitments.

The following detailed description of the preferred embodiment is divided into the following sections for ease of reference.

Section I provides a general overview of the systems and methods of business process management according to the present invention.

Section II describes the concept of business commitment according to the present invention.

Section III provides the BPCL for the conceptual level for specifying business commitments, as well as the preferred structures and components of the BPCL, and an exemplary XML Schema definition (XSD) that defines the BPCL content model, according to embodiments of the present invention. explain.

Section IV monitors business level SLAs using probe points, KPIs (Key Performance Indicators), and business commitments that can be used to implement a business process management platform. Systems and methods according to various embodiments of the invention that are controlled will be described.

Section V describes a number of exemplary business processes that can be implemented using the business commitments of the present invention.

Section I-Overview In general, the present invention relates to business process management systems and methods that can be implemented to manage various e-services related to "dynamic e-business". "Dynamic e-business" refers to an integrated set of applications and procedures that make up a cross-enterprise business process, such as customer relationship management (CRM) and supply chain management (SCM). Since a business entity can operate its business using multiple e-services, it is preferable to manage such e-services in a uniform manner. The business process management systems and methods according to the invention can effectively coordinate the execution of multiple applications, and audit trails and exceptions generated from such applications are managed from a business level view. It is preferable to be done.

In a preferred embodiment of the present invention, business process management at the business level includes centralized management of business relationships between business entities such as service providers, service consumers, and internal departments. Commitments are defined to capture the essence of business relationships in e-services. As explained in more detail below, a business commitment is a commitment related to a business issue, such as the service level of a service contract and the terms and conditions of a procurement contract. Business commitments are preferably specified using an XML-based language called BPCL (Business Process Commitment Language) herein and are used to monitor and control the execution of e-services.

Advantageously, the business commitment and BPCL according to the embodiments of the present invention provide a mechanism for model-based management of dynamic e-business solutions. Specifically, Business Commitments and BPCL effectively model business relationships between different business partners and interactions between internal parties, centrally managing business commitments with multiple parties. Provide a mechanism to do so. In other words, Business Commitment and BPCL allow you to manage a global / integrated view of different business relationships, thus leading to the best solution for business relationship management.

Section II-Business Commitment This section describes the concept of business commitment according to the present invention. In general, a commitment is an agreement or pledge to do (or not do) within certain limits in the future. According to the present invention, a business commitment is broadly defined as a commitment regarding a business problem. Business commitments can be between business partners, service requesters, and business partners or external partners such as service providers (external commitments) or between internal parties within a business enterprise (internal commitments). Business commitments can range from business contracts between two business partners, service level agreements (SLAs) between service providers and service requesters, or internal SLAs or combinations of these, as specified by a department. Can exist in the form of (as opposed to traditional SLA methods involving only two major parties).

The business commitment according to the invention is preferably viewed in the context of business process management. A business process is a fully coordinated thread of serial and parallel activities that collectively achieves a business purpose or policy goal. As a result, business processes can deliver value to both internal and external customers. Business Process Management (BPM) is the ability to discover, design, simulate, deploy, execute, optimize, and analyze end-to-end processes.

The Business Commitment pair establishes a management agreement for a BPM (Business Process Management) platform at the business process level, where explicit "actions" are associated with the business commitment. At run time, if an agreement / guarantee (defined by a business commitment) is breached, one party takes an action to either notify the relevant party or "fix" the breach. I promise that. BPM configures, controls and monitors business processes based on business commitments defined using BPCL in accordance with the present invention.

The concepts of business commitments, contracts and SLAs are related but have different focal points. The contract or SLA contains terms and conditions that all parties must agree to each other. Commitments are usually directional, which means that commitments have one initiator and one receiver. For example, in a shipping SLAs, the shipping company promises (to the service requester) that the goods will be shipped within X days. On the other hand, the service requester promises (to the shipping company) to pay the bill within Y days. During execution, commitments may be violated for a variety of reasons (unpredictable events or intentional violations by one party). Therefore, it is common for both parties to agree to take some "action" when mutual commitment is not satisfied. Therefore, according to the present invention, "action" is the main focus. Agreements (implemented by business commitments) are monitored and breaches are detected. As explained below, the monitoring and control of business commitments according to the present invention is based on a well-formed formula (condition) for business data concerns that monitors the parties.

Section III-Business Process Commitment Language (BPCL) In the next section, we provide an exemplary XML Schema definition (XSD) that defines the BPCL, preferred structures and components of the BPCL, and the BPCL content model for the conceptual level for specifying business commitments, according to embodiments of the present invention. explain.

Business commitments are jointly defined by the business process owner and the owner of the BPM platform on which the business process runs. The BPM system according to the invention monitors not only the execution of individual contracts, but also the relationships between these contracts. The relationship between multiple contracts / SLAs is referred to herein as an "inter-contract / SLA clause. Managing an inter-contract / SLA is a traditional single business process. It is beyond the scope of a management system.

With reference to Figure 1, the figure shows how to create a BPCL. Suppose Party 1 (P1) is the primary party and negotiates with multiple parties (P2, P3, and P4). The result of negotiations between P1 and P4 is SLA1 (1) (assuming P1 and P4 have arranged a service contract). The result of the negotiation between P1 and P3 is Contract 2 (2), and the result of the negotiation between P1 and P2 is Contract 3 (3) (if such negotiation is based on a general business contract). Assuming). A P1 can have an internal SLA / commitment (4) that describes the obligations of various internal departments. Since SLA1 (1), Contract 2 (2), and Contract 3 (3) are the result of separate negotiations, such results are processed via the Intercontract / SLA analysis (5) and are possible inter. A contract / SLA close is generated. Then, as shown in Figure 1, the resulting intercontract / SLA closes are internal SLA / commitment (4), SLA1, contract 2, and contract 3 (these are all from the perspective of P1). In combination with), a BPCL (6) is formed. It should be understood that the method described in Figure 1 can be manual or automatic.

According to a preferred embodiment of the invention, the BPCL is preferably based on XML syntax to specify business commitments. Furthermore, the BPCL is preferably based on the ECA (Event-Condition-Action) paradigm, where if an "event" occurs, the "condition" is evaluated and the "condition" is evaluated as true. , One or more "actions" are taken. BPCL is an extension of the ECA model in many ways. In general, the "condition" part of the ECA model contains formulas based on KPIs (key performance indicators) and commitment variables. Commitment variables generally include thresholds that can be dynamically set by business analysts. In addition, the BPCL contains a "commitment profile" that provides the values of the condition matching and commitment variables. A "commitment profile" provides a form that separates the logical part of a business commitment from the data part of a business commitment. In addition, the "action" part of the ECA model can be extended to an "action set" to execute a set of related actions either sequentially or in parallel.

Specifically, according to embodiments of the present invention, systems and methods of designating BPCL and monitoring business commitments through BPCL are supported by KPIs (Key Performance Indicators) and probe points. .. During normal e-service execution, there is a large amount of data exchanged between the service provider and the service consumer. KPIs provide a mechanism to separate business commitment monitoring from the low-level details of e-service implementations. A KPI is a specified parameter of an e-service that can be used to specify the status of the e-service. In other words, KPIs are one type of business process data that provides an indication of the performance (or status) of a business process. According to the present invention, KPIs are monitored and controlled by BPCL compliant systems. It should be understood that not all data generated by a business process is considered a KPI. The choice and definition of KPIs is preferably determined by a business analyst who has a detailed understanding of the business (or service).

For example, KPIs can be given directly from the contract. For example, in a shipping contract between a shipping company and a service requester, the shipping schedule and payment schedule can be KPIs. In addition, KPIs can request additional calculations based on subordinate metrics. For example, in an IT service, system availability can be calculated based on the continuous probing of the system over a period of time. In addition, KPIs can be derived from gathering information from the business context, which can be part of a business environment that is intentionally externalized by the owner of the business process.

The concept of KPIs was defined in areas such as Balanced Scorecard, Business Intelligence, and Supply Chain Management to specify metrics that can be used to measure the performance of enterprise and business processes. .. In the Balanced Scorecard example, KPIs are attached to the four perspectives of business metrics (ie, performance measurements): finance, customer satisfaction, internal processes, reforms and improvements. KPIs are preferably measurable, otherwise KPIs cannot be monitored, calculated and controlled. Examples of measurable metrics, and thus KPIs, in the supply chain domain include inventory levels and business process cycle times. According to the present invention, once a KPI extracted from a business process is determined, the KPI can be used to construct a meaningful relationship between business entities. The hypothetical business commitment is, for example, "KPIs from Business Process 1"₁Is a KPI from Business Process 2₂If it is larger, the administrator will be notified. "

Further, according to the present invention, the "probe point" provides a linkage between the business process modeling / execution language and the BPCL. The probe point contains a logical locator (inside a concrete business process) that reports relevant process data to the process monitoring / control system.

The following declarative fragment shows an exemplary XML Schema definition (XSD) that defines the components and structure of an exemplary XML-based BPCL document according to an embodiment of the invention.

Specifically, the following XSD fragment provides an exemplary type definition of an element of a BPCL document according to an embodiment of the invention. &lt;!-BPCLType definition-&gt; &lt;xsd: complexTypename = "BPCLType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "Party" type = "bpcl: PartyType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "BusinessProcess" type = "bpcl: BPType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "KPI" type = "bpcl: KPIType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "BusinessEvent" type = "bpcl: BEType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "BC" type = "bpcl: BCType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: elementname = "CommitmentProfile" type = "bpcl: CommitmentProfileTypes" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt; &lt;xsd: element name = "BusinessSLA" type = "bpcl: BPCLType /&gt;

In general, the element BusinessSLA of type BPCLType is the root element of the BPCL definition, as shown in the example XSD fragment above. BusinessSLA contains elements named Party, BusinessProcess, KPI, BusinessEvent, and BC. By convention, BPCL elements and types are defined in the namespace bpcl.

The Party element allows descriptive information to be included in the BPCL document regarding the parties participating in the business process of a business process management (BPM) system. The BusinessProcess element allows an abstract description of the targeted business process in the BPCL document. KPI elements allow key performance indicators or parameters that indicate the status of a business process to be included in the BPCL document. The BusinessEvent element allows the BPCL document to include events that provide triggering points that evaluate the internal formulas of individual business commitments. BC element (Business Commitment) is a key element of BPCL. The BC element allows the BPCL document to specify various network methods such as BCIdentifier, TriggeringEvent, CommitmentLevel, Validity, formulas for KPIs, Initiator, Receiver, Action, and AltAction, where BCIdentifier is the commitment An identification, the TriggeringEvent indicates which event triggers the evaluation of the commitment. The element Action is used to describe the action that takes place when the formula evaluates to true, and the AltAction indicates the alternative action that takes place when the logical Expression evaluates to false.

Each of the named elements in the exemplary BPCLType XSD definition contains a type attribute that references (points to) the name of the complex type used to define the element. For example, the following example XSD fragment defines a complex PartyType, which is pointed to by the Party element in the BPCLType definition above. &lt;xsd: complexTypename = "PartyType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "PartyIdentifier" type = "bpcl: PartyIdentifierType" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "Contact" type = "bpcl: ContactInformationType" /&gt; &lt;xsd: element name = "RolePlayer" type = "xsd: string" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;/ xsd: sequence&gt; &lt;xsd: attribute name = "name" type = "xsd: string" /&gt; &lt;/ xsd: complexType&gt;

As shown in the list, a composite PartyType is assumed to have a sequence of child elements in the declared order of PartyIdentifier (identifier information), Contact (contact information), and zero or more occurrences of RolePlayer. It is defined. In addition, the optional name attribute is defined as having a character string type. There is one main party that owns the Business Commitment Hub. There is one or more parties participating in the activities of the Business Commitment Hub.

The following exemplary XSD fragment then defines a composite element BPType, which is pointed to by the BusinessProcess element in the BPCLType definition above. &lt;!-Abstract Business Process Model-&gt; &lt;xsd: complexTypename = "BPType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "ProcessID" type = "xsd: string" /&gt; &lt;xsd: element name = "Activity" type = "bpcl: ActivityType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "ControlFlow" type = "bpcl: ControlFlowType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "DataFlow" type = "bpcl: DataFlowType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "Description" type = "xsd: string" /&gt; &lt;xsd: element name = "OverviewURL" type = "xsd: anyURI" /&gt; &lt;xsd: element name = "ProcessOwner" type = "xsd: string" /&gt; &lt;xsd: elementname = "ParticipantParty" type = "xsd: string" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "BPM" type = "bpcl: BPMType" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the list, the complex element BPType has ProcessID, 0 or more occurrences of Activity, 0 or more occurrences of ControlFlow, 0 or more occurrences of DataFlow, Description, OverviewURL, ProcessOwner (owns the process). A party), one or more occurrences of a ParticipantParty, and a sequence of child elements in the declared order BPM (to specify the type of the BPM system).

The following exemplary XSD fragment then defines a composite element KPIType, which is pointed to by the KPI element in the BPCLType definition above. &lt;xsd: complexTypename = "KPIType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "KPIName" type = "xsd: string" /&gt; &lt;xsd: element name = "KPIType" type = "xsd: string" /&gt; &lt;xsd: element name = "KPICategory" type = "bpcl: KPICategoryType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: choice&gt; &lt;!-Valued from business process-&gt; &lt;xsd: elementname = "ProcessAssociation" type = "bpcl: ProcessAssociationType" /&gt; &lt;xsd: elementname = "EventName" type = "xsd: string" /&gt; &lt;xsd: elementname = "InvocationURL" type = "xsd: anyURI" /&gt; &lt;xsd: elementname = "ObjectMethodName" type = "xsd: string" /&gt; &lt;xsd: elementname = "QueryString" type = "xsd: string" /&gt; &lt;!-Calculate values based on other KPIs-&gt; &lt;xsd: element name = "Computation" type = "bpcl: FunctionType" /&gt; &lt;!-Deriving values from basic KPIs-&gt; &lt;xsd: elementname = "ValueDerivation" type = "bpcl: ValueDerivationType" /&gt; &lt;/ xsd: choice&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the example above for a composite element KPIType, there are three different ways to get a value for a KPI: calculate the value based on another KPI directly from the business process, and get the value from the base KPI. There is a derivation.

The following exemplary XSD fragment then defines a complex BEType, which is pointed to by the BusinessEvent element in the BPCLType definition above. &lt;xsd: complexTypename = "BEType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "EventName" type = "xsd: string" /&gt; &lt;xsd: element name = "EventType" type = "xsd: string" /&gt; &lt;xsd: element name = "ProcessID" type = "xsd: string" /&gt; &lt;!-Event Source: Sender (coming directly from the sender) Or either Timer (comes from a timer)-&gt; &lt;xsd: choice&gt; &lt;xsd: element name = "Sender" type = "xsd: string" /&gt; &lt;xsd: element name = "Timer" type = "bpcl: TimerType" /&gt; &lt;/ xsd: choice&gt; &lt;xsd: element name = "Receiver" type = "xsd: string" minOccurs = "0" /&gt; &lt;xsd: element name = "EventAttributes" type = "bpcl: EventAttributesType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the list, complex BETypes are declared to have 0 or more occurrences of EventName, EventType, ProcessID, Sender or Timer (selection of event source), Receiver, and 0 or more occurrences of EventAttributes. It is defined as having a sequence of child elements in the same order. In an exemplary embodiment, the event mode includes multiple event sources, namely Sender (coming directly from the sender) or Timer (coming from the timer). Information specific to an event is stored in Event Attributes.

The following exemplary XSD fragment then defines a complex BCType, which is pointed to by the BC (Business Commitment) element of the BPCLType definition above. &lt;xsd: complexTypename = "BCType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "BCIdentifier" type = "xsd: string" /&gt; &lt;xsd: element name = "TriggeringEvent" type = "xsd: string" /&gt; &lt;xsd: element name = "CommitmentLevel" type = "bpcl: CommitmentLevelType" /&gt; &lt;xsd: element name = "Validity" type = "bpcl: PeriodType" /&gt; &lt;xsd: element name = "Expression" type = "bpcl: LogicExpressionType" /&gt; &lt;xsd: element name = "Initiator" type = "xsd: string" /&gt; &lt;xsd: element name = "Receiver" type = "xsd: string" /&gt; &lt;xsd: element name = "Action" type = "bpcl: ActionType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "AltAction" type = "bpcl: ActionType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the list, complex BCTypes are declared to have 0 or more occurrences of BCIdentifier, TriggeringEvent, CommitmentLevel, Validity, (logical) Expression, Initiator, Receiver, Action, and 0 or more occurrences of AltAction. It is defined as having a sequence of child elements in the same order.

Action defines one or more actions to take when a logical expression evaluates to true. AltAction defines one or more actions to take when a logical expression evaluates to false. Commitments are directional and therefore preferably indicate Initiators and Receivers. It is preferable to have multiple possible values for the Commitment Level, including the individual level (commitment per transaction instance) and the process level (based on the aggregated results over a period of time).

The following example XSD fragment then defines a composite ActionType, which is pointed to by both the Action and AltAction elements of the BCType type definition. &lt;xsd: complexTypename = "ActionType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "ActionCategory" type = "bpcl: ActionCategoryType" /&gt; &lt;xsd: element name = "ProcessID" type = "xsd: string" /&gt; &lt;xsd: element name = "ActivityName" type = "xsd: string" /&gt; &lt;xsd: element name = "Parameter" type = "bpcl: NameValueType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: element name = "ExecutionMode" type = "bpcl: ExecutionModeType" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the list, a composite element ActionType is defined as having zero or more occurrences of ActionCategory, ProcessID, ActivityName, Parameter, and a sequence of child elements in the declared order of ExecutionMode. The element ExecutionModeType is defined using enumeration constraints to limit the contents of such elements to multiple valid values, including "Sequentially" (sequential execution of actions) and "InParallel" (parallel execution of actions). Is preferable.

The following exemplary XSD fragment then defines a composite element CommitmentProfileType, which is pointed to by the CommitmentProfile element in the BPCLType definition above. &lt;xsd: complexTypename = "CommitmentProfileType"&gt; &lt;xsd: sequence&gt; &lt;xsd: element name = "ConditionMatchingVariable" type = "bpcl: NameValueType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;xsd: elementname = "CommitmentVariable" type = "bpcl: NameValueType" minOccurs = "0" maxOccurs = "unbounded" /&gt; &lt;/ xsd: sequence&gt; &lt;/ xsd: complexType&gt;

As shown in the list, a composite element CommitmentProfileType is defined as having a sequence of child elements in the declared order of zero or more occurrences of ConditionMatchingVariable and zero or more occurrences of CommitmentVariable.

As noted above, the CommitmentProfile describes conditional matching variables and commitment variables. The commitment profile separates the logical part of the commitment from the data part of the commitment, which allows for scalability when assembling large BPCL documents. The logical part of the commitment contains formulas for KPIs and parameters. The data part of the commitment contains the values of such parameters, and the data part contains a collection of data called a commitment profile. The data portion can reside in a database table or other separate XML document. In this way, the core of the BPCL can be made smaller and easier to understand. Each commitment profile contains multiple components, including (i) identification information and (ii) threshold information. The identification information is referred to as ConditionMatchingVariable, and the threshold information is referred to as CommitmentVariable. As the name implies, the ConditionMatchingVariable value is used as a condition for retrieving the CommitmentVariable value. CommitmentVariables participates in the evaluation of the logical part of the commitment. The result of such an evaluation determines whether one or more actions should be taken.

Section IV-BPM Systems and Methods The next section monitors business-level SLAs using probe points, KPIs (key performance indicators), and business commitments that can be used to implement a business process management platform. , Systems and methods according to various embodiments of the invention to control.

It should be understood that the systems and methods according to the invention described herein can be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. The present invention is tangibly implemented on one or more program storage devices (eg, hard disks, magnetic floppy disks, RAM, CD Rom, DVD, ROM, and flash memory) and includes devices with the appropriate architecture. Alternatively, it is preferably implemented in software as an application containing program instructions that can be executed by a machine.

In addition, the configuration system modules and method steps shown in the accompanying drawings are preferably performed in software so that the actual connection (or process step flow) between the system components is programmed by the application. Please understand that it may vary depending on the shape. Given the teachings herein, one of ordinary skill in the art can contemplate these and similar implementations or configurations of the invention.

With reference to FIG. 2, the figure shows a system and method of monitoring and controlling a business level SLA through probe points, KPIs, and business commitments according to embodiments of the present invention. It should be understood that Figure 2 also shows a high-level flow diagram of how to monitor and control business level SLAs according to embodiments of the present invention. In general, a system (10) architecture includes multiple integrated systems of components, including (i) build-time system components and (ii) run-time system components.

During build, the BPCL composer (11) is used to create one or more BPCL documents (12). Business analysts use the composer (11) tool to assemble BPCL documents. It is preferred that the BPCL composer (11) include a visual editing tool for assembling a valid BPCL document. In a preferred embodiment, the BPCL composer (11) includes an Eclipse-based visual development tool (via GUI) that displays the relationships between probe points, KPIs, and business process commitments. The final result of the edit is preferably stored in XML format as a BPCL document.

System (10) Run-time components include a BPCL configurator (13), actuator (14), condition evaluator (15), KPI calculator (16), and evaluation trigger (17). The BPCL configurator (13) processes BPCL documents and other configuration files to configure system components (14-17). The configurator (13) preferably contains a program that reads the BPCL document and passes the configuration information to the appropriate system components. Actuator (14) contains a program that calls management directives that can send generic notifications or change the execution of a running business process (18). The KPI calculator (16) contains a program that determines the KPI value, and the condition evaluator (15) contains a program that evaluates the logical condition. The evaluation trigger (17) determines the "trigger" for calling the condition evaluator (15). It is preferred that multiple types of triggers be implemented, including "alarm-based" and "event-based" triggers. For alarm-based triggers, the instructions are from the BPCL configurator (13) reading the BPCL document, while event-based triggers are based on probe messages.

SLA monitoring is done during the execution of system (10) and when the probe point is activated during the execution of a running business process (18). Specifically, the probe point inserted into the monitored business process is activated and sends a message to the KPI calculator (16). The KPI calculator (16) determines the KPI value. At the same time, the probe point also sends a message to the evaluation trigger (17), which requests the condition evaluator (15) to evaluate the associated logical condition. The conditional evaluator (15) requests a KPI value from the KPI calculator (16), and the KPI calculator (16) sends the data to the conditional evaluator (15). The conditional evaluator (15) then instructs the actuator (14) to take the appropriate action. The actuator (14) calls a generic notification mechanism, which calls the actual implementation of the notification, such as email, instant messaging, and so on. Actuators (14) can call one or more management directives that can change the execution of the underlying business process.

So, in summary, when the probe point is activated, the KPI value is calculated and then the (logical) condition is evaluated. The result from the conditional evaluation determines whether or not an SLA violation has occurred. In the event of such a breach, generic notifications are sent to the appropriate parties or management directives are routed back to the business process to manipulate the execution of the business process.

FIG. 3 is an exemplary diagram of a BPCL document assembled using a BPCL composer according to an embodiment of the present invention. As noted above, the BPCL composer is an Eclipse-based development tool that allows business analysts to visually define different components of a BPCL document and show the relationships between the different components of a BPCL document. Is preferable. As is well known in the art, the Eclipse Platform is Java-based, designed to create an integrated development environment (IDE) that can be used to create different types of applications, such as e-business applications. It is an open source software platform. Eclipse The Platform is built on a mechanism that discovers, integrates, and executes modules called plugins. Tool providers can work with files in the Eclipse "workspace" and develop tools as separate plug-ins that expose the tool-specific UI in the Eclipse "workbench". The Eclipse Workbench is an open source initiative that provides a platform on which Tool Builder can develop products. With all the common functionality available within the workbench, Tool Builder can focus on developing plug-ins that contain only core business logic. The Eclipse platform allows developers to use software tools from multiple suppliers together and integrates the business processes they use to create e-business applications. To do.

In the exemplary diagram of Figure 3, three basic layers: the probe point layer (L1), the KPI layer (L2), and the business commitment layer (L3) are shown for the BPCL definition. Since the KPI definition is recursive, the KPI layer (L2) may actually have multiple physical layers. For example, Figure 3 shows three KPI layers for the KPI layer (L2). The KPIs defined in the top KPI layer (31) are used to configure business commitments (30) and are defined under the top KPI layer (31) (32, 33, 34). ) Is used to calculate the "average base request response time" value for the top KPI layer (31). The exemplary document contains two probe points (35, 36) defined to activate monitoring for "base request start time" and "base request end time", respectively. Therefore, as shown in Figure 3, the business commitment definition depends on the KPI, and the KPI definition depends on the probe point. There is a dependency chain, for example "Probe Point-&gt; KPI-&gt; Business Commitment". When there are multiple probe points, KPIs, and business commitments, their interactions form a graph structure.

FIG. 4 is a diagram showing the architecture of the evaluation trigger (17) according to the embodiment of the present invention. FIG. 4 further shows the mode of operation of the evaluation trigger (17) according to the present invention. As noted above, it is preferable to have multiple sources of signal, such as alarming instructions (41) and messages from probe points (42). The alarming instruction includes a time-based specification for the periodic occurrence of an event. For example, by the end of each week (for example, 6:00 pm every Friday) or the beginning of each month (for example, 9:00 am on the first day of every month), the system determines the average cycle time. This can be compared with the predefined thresholds. The alarming processor (43) contains a program that processes the alarming instructions (41) and sets the appropriate systems / components to actually generate the signal via the signal generator (45).

In addition, an evaluation trigger (42) can be received from the probe point. In this case, these messages are passed to the event processor (44) whenever the probe point receives information from the underlying business process. The event processor (44) performs event aggregation (for example, determines how many messages have been received within a specified time period). The event processor (44) sends a signal to the signal generator (45) to generate an appropriate triggering signal.

FIG. 5 is a flow chart showing a method for determining a KPI value according to an embodiment of the present invention. The flow chart of FIG. 5 shows the mode of operation of the KPI calculator (16) of FIG. First, when a request for a KPI value is received from the conditional evaluator (step 50), the KPI calculator (16) processes the configuration information provided by the configurator (13) (step 51) and determines the KPI type (step 51). 52). If the KPI is determined to be a composite type (affirmative determination in step 53), the operator is determined, the operand value is recursively calculated (step 54), and the processing flow returns to step 52.

On the other hand, if the KPI is not a composite type (determination of negation in step 53), it determines whether the KPI is based on an external function (step 55). If the KPI is based on an external function (affirmative decision in step 55), for example, call a function defined in a WSDL (Web Service Description Language) operation (step 56) and aggregate the final KPI value (step 58). On the other hand, if the KPI is not based on an external function (negative decision in step 55), the KPI value is extracted from the probe points (step 57) and the final values are aggregated (step 58). It then returns the final value to the conditional evaluator (step 59).

FIG. 6 is a flow diagram illustrating a method of evaluating logical conditions (related to business commitment) in response to probe points activated during the execution of a business process, according to an embodiment of the present invention. The flow chart of FIG. 6 shows the mode of operation of the condition evaluator (15) of FIG. First, when receiving a KPI value from the KPI calculator, the condition evaluator (15) processes the configuration information provided by the configurator (13) (step 60), and the primitive evaluation engine for each Boolean literal contained in the formula. (Step 61). The results from the evaluation of each Boolean literal are then aggregated (step 62) and the results are returned to the actuator (step 63).

FIG. 7 is a flow diagram showing how to determine the action taken in response to a business level SLA violation. FIG. 7 shows the mode of operation of the actuator (14) of FIG. As noted above, based on the results of the condition evaluation, the condition evaluator (15) instructs the actuator (14) to take the appropriate action. The actuator (14) processes the configuration information provided by the configurator (13) (step 70) and, in response to a request from the condition evaluator (15), determines the type of action to take (step 71). If generic notification is specified (affirmative decision in step 72), the evaluation result is inspected and the appropriate party is notified (step 73). If no generic notification is specified (negative decision in step 74), check the evaluation result and call the appropriate management directive (step 74).

As mentioned above with respect to Figure 3, business commitment definitions are based on KPIs, which are defined by probe points. There are dependency chains such as "Probe Point-&gt; KPI-&gt; Business Commitment". When there are multiple probe points, KPIs and business commitments and their interactions form a graph structure. If the probe point is unavailable for any reason (ie, a partial failure of a business process), it must have a form that detects the affected KPIs and business commitments.

FIG. 8 is a flow diagram showing a method of detecting a dependency between a KPI and a business commitment when a probe point is unavailable, according to an embodiment of the present invention. In such a method, the input contains a list of probe points that are (temporarily or permanently) unavailable, and the output contains a list of KPIs and business commitments that are correspondingly affected. First, for each business commitment defined in the BPCL document, the conditional part of the definition is analyzed and the relevant set of KPIs for each business commitment is returned (step 80). This set, KPI_BC1, KPI_BC2, ..., KPI_BCnAnd so on.

It then traverses the child nodes for each KPI defined in the BPCL document and returns all supported pairs of probe points for each KPI (step 81). This set, PP_KPI1, PP_KPI2, ... PP_KPInAnd so on.

Then get one probe point from the input list (remove it from the list) (step 82). The probe point is a set of probe points PP_KPI1, PP_KPI2, ... PP_KPInIt is determined whether or not it is a member of any of the above (step 83). If the probe point is a member of one such probe point set (a positive decision in step 83), add the KPI name to the "output KPI list" (step 84). If the input list still has probe points (a positive decision in step 85), repeat this process (steps 82, 83, and 84) until the input list is empty (a negative decision in step 85).

A copy of the "output KPI list" when the probe point input list is empty_output(Step 86). Then one KPI to KPI_outputObtained from KPI_outputRemove from (step 87). Determine whether the KPI obtained from the output list is a member of any of the KPI sets obtained in step 80 (step 88). If the KPI is a member of the pair (affirmative decision in step 88), add the corresponding business commitment name to the "output BC list" (step 89). Output list KPI_outputIf there are still probe KPIs in (step 90 affirmative), repeat this process (steps 87, 88, and 89) until the output list is empty (step 90 negative). Returns an "output KPI list" and an "output BC list" (step 91).

Section V-Case Study The following sections describe a number of exemplary business processes that can be implemented using the business commitments of the present invention.

1. Insurance hub In the insurance industry, small companies can buy insurance policies through independent agencies. These independent agents contact the insurer who actually issues the insurance policy. Since it is time consuming for an independent agent to handle a large number of insurers with potentially different securities, the results returned by multiple insurers can be aggregated and a uniform interface can be provided to the independent agents. It is cost effective to develop an insurance hub (using the business process management systems and methods described herein). During a business interaction between an insurer and an insurer, the insurer may find that the securities rules provided by the insurer do not match the real-world situation. The insurance hub can send a rule set revision request to the insurer. Since securities rule changes require human intervention, insurers can take hours or days to process the rule set and send the results back to the hub. From the perspective of an insurance hub, it would be beneficial if each insurer could return the corresponding results within the agreed time period. The value of such a time period can be part of an SLA / contract between the insurance hub and the insurer.

According to the present invention, multiple commitments can be defined in the above example. One commitment is from the insurer to the insurance hub, in which case the insurer must return the results within a specified time period and the insurance hub monitors the results. Another commitment is from the insurance hub to the insurer, in which case at the end of each reporting period, the insurance hub reports the average turnaround time to the insurer.

2. Supply chain management In large manufacturing companies, the manufacturing facility may be separate from the inventory center for efficiency. Manufacturing facilities handle a variety of channels, which are the actual customers of the manufacturing company. The inventory center orders raw materials from the supplier. According to the present invention, the interactions between these four entities (manufacturing facilities, inventory centers, customers, and suppliers) are modeled as e-services, and the business relationships between such entities are Modeled as a business commitment on such e-services. In this example, various commitments can be defined. For example, one commitment can be defined as "customer service potential", which is a commitment from the manufacturing facility to the channel. Depending on the channel / customer class, the on-time percentage can be set to 95%. In addition, delivery can be considered "on time" if delivery is completed within a predefined delivery time, such as 3 or 4 days.

Another commitment can be defined as "supplier replenishment", which is a supplier-to-inventory center commitment. Depending on the supplier name, part name, or part family name, the inventory center must have a cycle time of less than 2 days, a standard deviation of less than 4 hours, and an error tolerance of 2. It can be requested that it must be less than an hour.

Another commitment can be defined as "prediction accuracy". Depending on the part name or part family name, the "prediction accuracy" must be greater than 80%.

In the above example, KPIs, condition matching variables, and commitment variables are obvious. For example, in the third commitment, "ForecastAccuracy" is the KPI, PartName or PartFamilyName is ConditionMatchingVariable, and 80% is the value of CommitmentVariable (for example, $ FA). At runtime, the value of $ FA can be changed dynamically, thus effectively changing commitments on the fly.

Although exemplary embodiments have been described herein with reference to the accompanying drawings, the present invention is not limited to the exact systems and methods described herein and does not deviate from the scope and gist of the present invention. It should be understood that those skilled in the art can bring various other changes and modifications. All such changes and modifications are intended to be included in the scope of the invention as defined by the claims.

<figref num="1">It is a flow chart which shows the method of making a BPCL document by embodiment of this invention.</figref><figref num="2">FIG. 5 illustrates a system and method of monitoring and controlling business level SLAs through probe points, KPIs, and business commitments according to embodiments of the present invention.</figref><figref num="3">It is an exemplary diagram showing a BPCL document assembled using a BPCL composer according to an embodiment of the present invention.</figref><figref num="4">It is a flow chart which shows the method of generating the triggering signal by the evaluation trigger module by embodiment of this invention.</figref><figref num="5">It is a flow chart which shows the method of determining the KPI (key performance indicator) value by embodiment of this invention.</figref><figref num="6">It is a flow diagram which shows the method of evaluating a logical condition (related to a business commitment) in response to a probe point activated during the execution of a business process according to the embodiment of the present invention.</figref><figref num="7">It is a flow chart which shows the method of determining the action taken in response to a business level SLA violation.</figref><figref num="8">It is a flow chart which shows the method of detecting the dependency between a KPI and a business commitment when a probe point is unavailable according to the embodiment of the present invention.</figref>

Code description

1 SLA1 2 contract 2 3 contract 3 4 Internal SLAs / Commitments 5 Intercontract / SLA analysis 6 BPCL P1 Party 1 P2 Party 2 P3 Party 3 P4 Party 4 10 system 11 BPCL composer 12 BPCL document 13 BPCL configurator 14 Actuator 15 Condition Evaluator 16 KPI Calculator 17 Evaluation trigger 18 Business process 30 Business Commitment 31 KPI layer 32 KPI 33 KPI 34 KPI 35 probe points 36 probe point 41 Alarming instructions 42 Message from probe point 43 Alarming Processor 44 event processor 45 signal generator