A Business Process Model Engine (BPM Engine) typically is responsible for the execution of a well-defined business process, e.g., in a complex, distributed computing environment where a business process model (BPM) may be used.
The data that may be provided to the BPM Engine typically is limited to very specific formats. Despite this typical limitation, the number of available formats of data is quite large and the available formats are quite broad in scope and content. For example, information may be provided from structured data files, user-entered fields in a defined user interface (UI), triggers in a database, forms, etc. Each such technique for data input typically supports the complex translation of the input data into a structure that is meaningful to the BPM Engine.
In this context, the “complex translation of the input data” means that the author of the business process model and its input trigger must have knowledge of (1) the BPM Engine trigger format, and also (2) the format of the source data to be able to translate the input source data into a form that is understood by the BPM Engine.
Oftentimes, the BPM Engine uses data in a form that is referred to as a template or document type, and the structure of that document generally is well defined, and highly controlled to help ensure that the BPM Engine receives information in a format that it understands.
Conventionally, electronic forms or e-forms have been used by corporations, courts, states, hospitals, etc., to capture data. The structure of such e-forms, including the layout of fields, the data type of each field, the relationships between fields, etc., is generally flexible. As an example result, it will be appreciated that an e-form used to capture an address change would not look like an e-form used to capture a purchase order. That is, there typically will be differences both in terms of the layout of the e-form and the information gathered via the e-form.
Broad interactions exist with e-forms. For instance, when an organization captures data in an e-form it may, for example:    Store the e-form documents directly within internal systems, e.g., to satisfy regulatory requirements;    Manually extract, e.g., via scanning and optical character recognition (OCR), re-typing, etc., the data in the e-form into internal systems for further processing; and/or    Use e-form specific controls and/or e-form specific APIs to extract the data from the e-form and place the data into a structured format and/or file that may be parsed manually or programmatically.
With respect to storing the e-form documents directly within internal systems, a business process model may be used to move and/or store e-form documents into internal systems, and may not have the ability to interact with the contents or data of those documents. For example, the process may carry the e-form as an image attachment, but be unable to work with or use the data therein.
Although manually extracting the data in the e-form into internal systems for further processing may achieve an interaction with the e-form data, it nonetheless requires manual extraction of the data before a business process model may use it.
Using e-form specific controls and/or APIs to extract the data from the e-form and place the data into a structured format and/or file that may be parsed manually or programmatically may provide programmatic interaction with the e-form data. However, it may still require form-specific API knowledge to extract the e-form data for use in a business process model.
Given these shortcomings with certain conventional techniques used to capture data in an e-form, as well as the needs of the BPM Engine itself, it will be appreciated that the author of the business process model generally must understand the format and details of the e-form itself (e.g., its internal data model); the format and details of the BPM Engine internal data model; how to translate via APIs (or via manual steps) the format of, and data contained in, the e-form into a format that the BPM Engine understands; and/or the like.
Thus, it will be appreciated that there is a need in the art for techniques that enable transparent composition and decomposition of e-form data from one or more e-form formats into data that is directly usable by a Business Process Model Engine. For instance, it would be desirable to be able to compose and decompose e-form data from Adobe® LiveCycle®, Microsoft® InfoPath®, etc., e-forms, into data that is directly usable by a BPM Engine.
One aspect of certain example embodiments relates to a tool that helps support the creation of a document that triggers a business process model. Another aspect of certain example embodiments includes support for the creation of such trigger documents based on an e-form (e.g., an Adobe® LiveCycle®, Microsoft® InfoPath®, or other e-form) without the need for manual steps, and/or deep knowledge of, or use of, any vendor-specific APIs from the parent products.
One aspect of certain example embodiments relates to example transparent composition/decomposition techniques, e.g., for electronic forms used in connection with a Business Process Model (BPM) process. In certain example embodiments, such example transparent composition/decomposition techniques create a dynamic environment where, for instance, on-the-fly and/or dynamic editing of an e-form is possible with a reduce (or no) impact on a corresponding BPM process.
Another aspect of certain example embodiments relates to reducing and sometimes even eliminating the need for manual retyping and/or scanning of e-forms.
Another aspect of certain example embodiments relates to reducing and sometimes even eliminating the need for deep knowledge of the internal structure of the e-form itself.
Another aspect of certain example embodiments relates to reducing and sometimes even eliminating the need for deep knowledge of the data format required by the BPM Engine.
Another aspect of certain example embodiments relates to reducing and sometimes even eliminating the need for e-form vendor specific knowledge and/or APIs.
Still another aspect of certain example embodiments relates to making the contents of the e-form transparently available to trigger a BPM.
Still another aspect of certain example embodiments relates to making the contents of the e-form transparently available for programmatic interpretation by the BPM Engine.
Yet another aspect of certain example embodiments relates to transparently decomposing the contents of the e-form into a BPM-Engine understandable format.
Yet another aspect of certain example embodiments relates to transparently composing the contents of the BPM-Engine understandable format back into the e-form.
In certain example embodiments, a method of transparently decomposing, composing, and/or recomposing documents is provided. An electronic form (e-form) is received, with the e-form being created according to a first source type. An algorithm (which may be located in and/or executed from a data store, for example) with predefined rules for extracting information regarding the structure and/or layout of the e-form is consulted, via at least one processor, with at least some of the information to be extracted corresponding to structure and/or layout information that would be apparent if the e-form were viewed and at least some of the information to be extracted corresponding to structure and/or layout information that would not be apparent if the e-form were viewed. The information regarding the structure and/or layout of the e-form is extracted, via the at least one processor, based on the predefined rules. A template or document type is built, via the at least one processor, based on the extracted information, the template or document type being in a second source type different from the first source type. The template or document type is stored to a non-transitory storage location.
In certain example embodiments, a system for transparently decomposing, composing, and/or recomposing documents is provided. An interface is configured to receive an electronic form (e-form), with the e-form being created according to a first source type. An algorithm (which may be located in and/or executed from a data store, for example) includes predefined rules indicating how information regarding the structure and/or layout of the e-form is to be extracted, with at least some of the information to be extracted corresponding to structure and/or layout information that would be apparent if the e-form were viewed and at least some of the information to be extracted corresponding to structure and/or layout information that would not be apparent if the e-form were viewed. At least one processor is configured to: extract the information regarding the structure and/or layout of the e-form based on the predefined rules; build a template or document type based on the extracted information, with the template or document type being in a second source type different from the first source type; and store to a non-transitory storage location the template or document type.
In certain example embodiments, a method of transparently decomposing, composing, and/or recomposing documents is provided. A request for an e-form is received from a user, with the e-form being in a first format or of a first type. The e-form is built based on previously defined structure and format information about the e-form, and content data provided regarding the e-form. The user is able to edit the e-form, with the e-form being editable while in a second format or of a second type. The e-form is saved in the first format or first type based on the previously defined structure and format information about the e-form, and the user's edits.
In certain example embodiments, a system for transparently decomposing, composing, and/or recomposing documents is provided. An interface is configured to receive a request for an e-form from a user, with the e-form being in a first format or of a first type. At least one processor is configured to: build the e-form based on previously defined structure and format information about the e-form, and content data provided regarding the e-form; enable the user to edit the e-form, with the e-form being editable while in a second format or of a second type, and save the e-form in the first format or first type based on the previously defined structure and format information about the e-form, and the user's edits.
In certain example embodiments, a method of transparently decomposing, composing, and/or recomposing documents is provided. A request for an e-form is received from a user, with the e-form being in a first format or of a first type. The e-form is built based on previously defined structure and format information about the e-form, and content data provided regarding the e-form. The e-form is saved in a third format or third type based on further, different previously defined structure and format information about the e-form, and the user's edits. The first and third formats or first and third types are not directly understandable by a business process model (BPM) engine. The second format or second type is directly understandable by the BPM engine.
In certain example embodiments, there are provided non-transitory computer readable storage mediums tangibly storing instructions that, when executed by at least one processor of a system, perform the above-described and/or other methods.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.
USPTO Backgrounds
USPTO Backgrounds