U.S. patent application number 17/079950 was filed with the patent office on 2021-04-08 for methods and apparatus for exposing workflow process definitions as business objects.
The applicant listed for this patent is K2 Software, Inc.. Invention is credited to Jacobus Hendrik du Preez, Wynand Coenraad Du Toit, Pieter Janson, Adriaan van Wyk.
Application Number | 20210103862 17/079950 |
Document ID | / |
Family ID | 1000005287540 |
Filed Date | 2021-04-08 |
![](/patent/app/20210103862/US20210103862A1-20210408-D00000.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00001.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00002.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00003.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00004.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00005.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00006.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00007.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00008.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00009.png)
![](/patent/app/20210103862/US20210103862A1-20210408-D00010.png)
View All Diagrams
United States Patent
Application |
20210103862 |
Kind Code |
A1 |
van Wyk; Adriaan ; et
al. |
April 8, 2021 |
METHODS AND APPARATUS FOR EXPOSING WORKFLOW PROCESS DEFINITIONS AS
BUSINESS OBJECTS
Abstract
The present disclosure provides methods and apparatuses for
exposing a workflow processes definition as a business object.
Using the methods and apparatus herein, users can access a business
object representing a workflow process definition from any system
using standard database constructs. The data for the business
object may be combined from a variety of existing sources and/or
new data. Using the methods and apparatus a user may generate
reports from the business object.
Inventors: |
van Wyk; Adriaan;
(Snoqualmie, WA) ; Janson; Pieter; (Centurion,
ZA) ; Du Toit; Wynand Coenraad; (Johannesburg,
ZA) ; du Preez; Jacobus Hendrik; (Snoqualmie,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
K2 Software, Inc. |
Bellevue |
WA |
US |
|
|
Family ID: |
1000005287540 |
Appl. No.: |
17/079950 |
Filed: |
October 26, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12117455 |
May 8, 2008 |
10817811 |
|
|
17079950 |
|
|
|
|
60939270 |
May 21, 2007 |
|
|
|
60916706 |
May 8, 2007 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/06 20130101;
G06Q 10/0633 20130101 |
International
Class: |
G06Q 10/06 20060101
G06Q010/06 |
Claims
1. A method for exposing a workflow process definition as a
business object, the method comprising: creating a workflow
process, wherein the workflow process includes workflow data;
executing the workflow process; and creating a business object
based on the workflow process, wherein the business object includes
a database interface for accessing the workflow data and wherein
the business object includes data from a first source in a first
format and data from a second source in second format.
2. The method of claim 1, wherein the workflow data includes a
first data from a first back end system and a second data from a
second back end system.
3. The method of claim 1, wherein the database interface includes
an Insert, an Update, a Select, and a Delete method.
4. The method of claim 1, including creating a report on the
business object.
5. The method of claim 1, including retrieving the workflow process
data and an associated workflow process step from the business
object.
6. The method of claim 1, including creating custom methods
associated with the business object.
7. The method of claim 1, including creating a new data store for
storing new data, wherein the new data is associated with a new
data field created in the business object and the new data field is
not located in an existing data store.
8. A system for exposing a workflow process definition as a
business object, the system comprising: a processor: creating a
workflow process, wherein the workflow process includes workflow
data; executing the workflow process; and creating a business
object based on the workflow process, wherein the business object
includes a database interface for accessing the workflow data and
wherein the business object includes data from a first source in a
first format and data from a second source in second format.
9. The system of claim 8, wherein the workflow data includes a
first data from a first back end system and a second data from a
second back end system.
10. The system of claim 8, wherein the database interface includes
an Insert, an Update, a Select, and a Delete method.
11. The system of claim 8, including creating a report on the
business object.
12. The system of claim 8, including retrieving the workflow
process data and an associated workflow process step from the
business object.
13. The system of claim 8, including creating a custom method
associated with the business object.
14. The system of claim 8, including creating a new data store for
storing new data, wherein the new data is associated with a new
data field created in the business object and the new data field is
not located in an existing data store.
15. A computer readable medium storing a program to causing a
computer system to: create a workflow process, wherein the workflow
process includes workflow data; execute the workflow process; and
create a business object based on the workflow process, wherein the
business object includes a database interface for accessing the
workflow data and wherein the business object includes data from a
first source in a first format and data from a second source in
second format.
16. The computer readable medium of claim 15, wherein the workflow
data includes a first data from a first back end system and a
second data from a second back end system.
17. The computer readable medium of claim 15, wherein the database
interface includes an Insert, an Update, a Select, and a Delete
method.
18. The computer readable medium of claim 15, including creating a
report on the business object.
19. The computer readable medium of claim 15, including retrieving
the workflow process data and an associated workflow process step
from the business object.
20. The computer readable medium of claim 15, including creating a
custom method associated with the business object.
Description
PRIORITY CLAIM
[0001] The present application is a continuation of, claims
priority to and the benefit of U.S. patent application Ser. No.
12/117,455, titled "METHODS AND APPARATUS FOR EXPOSING WORKFLOW
PROCESS DEFINITIONS AS BUSINESS OBJECTS", filed on May 8, 2008,
which claims priority to and the benefit of U.S. Patent Application
No. 60/916,706, titled "METHODS AND APPARATUS FOR REPRESENTING
BUSINESS PROCESS INFORMATION AS BUSINESS ENTITIES", filed on May 8,
2007 and U.S. Patent Application No. 60/939,270, titled "METHODS
AND APPARATUS FOR EXPOSING WORKFLOW AND PROCESS DEFINITIONS AS
BUSINESS OBJECTS", filed on May 21, 2007, the entire contents of
which are incorporated herein by reference.
BACKGROUND
[0002] As the number of information sources in organizations are
growing, it is becoming increasingly difficult for consumers of the
information to access it in a logical and structured way that
relates to the traditional business objects they find familiar
within their organizations (e.g., customers, assets, vendors,
staff, etc). Data from existing systems is typically made available
in a technical way that requires significant technical and
development skills to surface it to non-technical users in the
organization. A workable mechanism is needed for non-technical
users to add information within a logical business object
definition without involving technical or development skills.
Similarly, a workable solution is needed to allow both technical
and non-technical users of data to access their information from
multiple data/information sources in a structured business object
like way, while still maintaining the flexibility to add additional
information definitions to the existing business objects or to
create new business objects from existing or new data sources
without the need for complex solution development.
[0003] Existing Enterprise Application Integration (EAI) systems
combined with development tools can be used to develop custom
solutions which make data and information more accessible, but
these solutions are hard-coded and require significant technical
and development skills to maintain and change over time.
Non-technical users need a workable way to change the definition of
the structured data (business objects) or to add additional
information sources or fields within existing business object
definitions that might already exist within their organizations.
For example, customer information might exist in a CRM system, ERP
system and a custom issue tracking system. Existing EAI solutions
assist in integrating data between these systems, but do not
provide a mechanism to see a single definition of a customer as a
logical business object regardless of where the information is
being sourced from.
[0004] In addition, information workers are limited by the static
business forms and information presented to them by the solution
applications or custom developed applications they use on a
day-to-day basis. Regardless of whether these forms are thin client
(web or browser) based or thick/smart client (windows forms) based,
the information worker's ability to add additional information
on-demand to existing forms based on its current state and context,
is extremely limited. Existing form technologies depend on a
developer's involvement to bind the form to a data source (web
service, database, etc) which populates the form with information
based on a user event (click of a button, etc). Should the end user
require additional information to be displayed on the form, he
needs to rely on application specific pre-developed functionality
that might allow him to see additional information or data fields
on the forms. This implementation however depends on the logic
encapsulated in the application or custom developed solution.
[0005] Still further, existing process automation tools do not
provide the necessary level of modeling tools and concepts to allow
both technical and non-technical users to author a completed
business process solution in a single modeling/automation tooling
environment. It is extremely difficult for business analysts,
business/process owner's technical people to use a single solution
which allows for all roles to work seamlessly together to rapidly
discover, model and automate business processes within
organizations. Existing workflow and business process automation
tools are disconnected and do not allow for a single environment
which brings technical and non-technical business users together
with a set of tools that deeply integrate the necessary building
blocks.
SUMMARY
[0006] The disclosed system uses Enterprise Application Integration
(EAI) sources (e.g., EAI software, Web Services, Application API)
to provide a higher level framework (e.g., runtime broker and
adapter services) with related solution components (e.g., user
interfaces and tooling) which empowers technical and non-technical
users to author logical business objects that include data
definitions (e.g., customer name, surname, etc) and actions or
methods (e.g., save, load, delete) from existing and/or new data
sources. Existing data sources include ERP, CRM, and/or custom
developed systems in an organization. New data sources are created
and maintained by the disclosed system. The system allows users to
combine data from multiple sources into one single business object
definition, including data and method/actions definitions. The new
logical business object exposes a single logical data structure and
view of the object as well as a single set of logical methods that
are associated with the object. For example, the logical business
object may implement standard SQL methods such as INSERT, UPDATE,
SELECT, DELETE, etc. The methods may act as stored procedures to
external interfaces and can take parameters to manipulate the data
result sets. For example, the INSERT method may take a number of
parameters for the INSERT operation to execute.
[0007] The object broker interprets the new object definition and
brokers data/information and method calls to the data sources (or
existing systems). Additional fields can be added to the new object
definition. These additional fields are associated with unique
identifiers from the other data sources included in the new object
definition. Data structures and actions (e.g., insert, update,
select, delete as examples) are managed by the object broker. The
actual data is stored in native format of the data store it
originates in and is not duplicated. The object broker creates a
dynamic business object whose definition can be changed by either
adding or removing data or actions without the need to involve
technical or development resources to reconfigure or recompile the
actual objects.
[0008] Existing systems are accessed through a service object
component. The service object for a specific back-end system
implements the base interface expected by the object broker. This
enables the object broker to use a consistent communication
mechanism to exchange data and function calls with the applications
it is integrating. The object broker, together with the service
object interface, provides the underlying infrastructure to
exchange data, method calls and participation in supporting
services such as transactions, compensations models, exception
handling and role/security management. The object broker also
includes a single-sign on implementation, which allows the object
broker to use a single credential set to access multiple systems
(each with their own authentication model).
[0009] The disclosed system also facilitates the creation of
automated business processes by both technical and non-technical
users. Business process design typically utilizes two main elements
of information that are part of the design time and run time
process information, the process instance data, or the actions that
were taken in the process, and the object data that is associated
with the process instance. The object data that is used in a
business process may be represented by the logical business
objects. By abstracting the business process data as logical
business objects, the system allows the user to access or alter the
information without needing to write code or complex database
queries. The logical business objects associated with a business
process can be edited and created in a similar manner to all other
logical business objects.
[0010] Additional features and advantages are described herein, and
will be apparent from, the following Detailed Description and the
figures.
BRIEF DESCRIPTION OF THE FIGURES
[0011] FIG. 1 is a high level block diagram of a communications
system.
[0012] FIG. 2 is a more detailed block diagram showing one example
of a computing device.
[0013] FIG. 3 is a block diagram showing example connections
between a plurality of data sources and an electronic form via an
object broker.
[0014] FIG. 4 is a block diagram showing example connections
between data sources and business objects.
[0015] FIG. 5 is a screenshot of an example business process.
[0016] FIG. 6 is a screenshot of an example business object
model.
[0017] FIG. 7 is a screenshot of an example data flow model.
[0018] FIG. 8 is a screenshot of an example deployment screen.
[0019] FIG. 9 is an example screenshot of a workflow screen.
[0020] FIG. 10 is an example screenshot of a business entity
selection screen.
[0021] FIG. 11 is an example screenshot of a data selection
screen.
[0022] FIG. 12 is an example screenshot of a workflow process
overview report screen.
[0023] FIG. 13 is an example screenshot of a process instances
report screen.
[0024] FIG. 14 is an example screenshot of a view flow report
screen.
DETAILED DESCRIPTION
[0025] The present system is most readily realized in a network
communications system. A high level block diagram of an exemplary
network communications system 100 is illustrated in FIG. 1. The
illustrated system 100 includes one or more client devices 102, one
or more routers 106, and a plurality of different data sources 108
including database servers 110 and/or databases 112. Data
transferred to/from the client devices 102 from/to the data sources
108 is managed by one or more object broker servers 114. Each of
these devices may communicate with each other via a connection to
one or more communications channels 116 such as the Internet and/or
some other data network, including, but not limited to, any
suitable wide area network or local area network. It will be
appreciated that any of the devices described herein may be
directly connected to each other instead of over a network.
[0026] The data sources 108 store a plurality of files, programs,
and/or web pages in one or more databases 112 for use by the client
devices 102. For example, a data source may store customer
information. The data sources 108 may be connected directly to a
database server 110 and/or via one or more network connections.
[0027] One data source 108 and/or one object broker server 114 may
interact with a large number of other devices. Accordingly, each
data source 108 and/or one object broker server 114 is typically a
high end computer with a large storage capacity, one or more fast
microprocessors, and one or more high speed network connections.
Conversely, relative to a typical server, each client device 102
typically includes less storage capacity, a single microprocessor,
and a single network connection.
[0028] A more detailed block diagram of the electrical systems of a
computing device (e.g., handheld client device 102, personal
computer client device 102, router 106, database server 110, and/or
object broker server 114) is illustrated in FIG. 2. Although the
electrical systems of these computing devices may be similar, the
structural differences between these devices are well known. For
example, a typical handheld client device 102 is small and
lightweight compared to a typical database server 110.
[0029] The example computing device 102, 106, 110, 114 includes a
main unit 202 which preferably includes one or more processors 204
electrically coupled by an address/data bus 206 to one or more
memory devices 208, other computer circuitry 210, and one or more
interface circuits 212. The processor 204 may be any suitable
processor, such as a microprocessor from the INTEL PENTIUM.RTM.
family of microprocessors. The memory 208 preferably includes
volatile memory and non-volatile memory. Preferably, the memory 208
stores a software program that interacts with the other devices in
the system 100 as described below. This program may be executed by
the processor 204 in any suitable manner. The memory 208 may also
store digital data indicative of documents, files, programs, web
pages, etc. retrieved from another computing device and/or loaded
via an input device 214.
[0030] The interface circuit 212 may be implemented using any
suitable interface standard, such as an Ethernet interface and/or a
Universal Serial Bus (USB) interface. One or more input devices 214
may be connected to the interface circuit 212 for entering data and
commands into the main unit 202. For example, the input device 214
may be a keyboard, mouse, touch screen, track pad, track ball,
isopoint, and/or a voice recognition system.
[0031] One or more displays, printers, speakers, and/or other
output devices 216 may also be connected to the main unit 202 via
the interface circuit 212. The display 216 may be a cathode ray
tube (CRTs), liquid crystal displays (LCDs), or any other type of
display. The display 216 generates visual displays of data
generated during operation of the computing device 102, 106, 110,
114. For example, the display 216 may be used to display web pages
received from the object broker server 114 including data from
multiple data sources 108. The visual displays may include prompts
for human input, run time statistics, calculated values, data,
etc.
[0032] One or more storage devices 218 may also be connected to the
main unit 202 via the interface circuit 212. For example, a hard
drive, CD drive, DVD drive, and/or other storage devices may be
connected to the main unit 202. The storage devices 218 may store
any type of suitable data.
[0033] The computing device 102, 104 may also exchange data with
other network devices 220 via a connection to the network 116. The
network connection may be any type of network connection, such as
an Ethernet connection, digital subscriber line (DSL), telephone
line, coaxial cable, etc. Users of the system 100 may be required
to register with one or more of the computing devices 102, 106,
110, 114. In such an instance, each user may choose a user
identifier (e.g., e-mail address) and a password which may be
required for the activation of services. The user identifier and
password may be passed across the network 116 using encryption
built into the user's web browser. Alternatively, the user
identifier and/or password may be assigned by the computing device
102, 106, 110, 114.
[0034] In one embodiment, a user at a client device 102 views
and/or modifies data from a plurality of different data sources 108
via an interactive electronic form. An example block diagram
showing connections between a plurality of data sources 108 and an
electronic form 302 via an object broker process 304 is illustrated
in FIG. 3. In general, the object broker process 304 (described in
detail below with reference to FIG. 6) compiles data in a variety
of different native formats from the different data sources 108
(e.g., different legacy database systems) into standardized
business objects 306, 308 (e.g., in a declarative format such as
XML). A user may then view the data using one or more electronic
forms 302, 310, 312. In addition, the user may manipulate the data
and/or add data via the electronic forms 302, 310, 312. When form
data is changed, the object broker process 304 accepts the data via
the business objects 306, 308 and stores the data back to the data
sources 108 in the correct native format.
[0035] In this example, the data sources 108 include an enterprise
resource planning (ERP) data source 314, a customer relationship
management (CRM) data source 316, a custom data source 318, an
add-on data source 320, and a function data source 322. In
addition, a role service 323 and an object data store 325 are
included in the system 300. Typically, an ERP data source 314
stores data related to accounts receivable, accounts payable,
inventory, etc. Typically, a CRM data source 316 stores data
related to leads, quotes, orders, etc. A custom data source 318 is
a data source 108 that is not considered a standard commercial
product. For example, a business may have a custom data source that
stores real-time manufacturing information. Some data sources 108
may use an intermediary server for communications. For example, the
ERP data source 314 may use a BizTalk server 324.
[0036] The add-on data source 320 stores data associated with form
fields added by the user that are not supported by one of the other
data sources 108. For example, a business may start up a frequent
shopper card program and need to store a card number for each
participant. Accordingly, a user may add a frequent buyer number
field to an existing form containing legacy data. Because the
existing data sources 108 in this example do not include a frequent
buyer number field, the frequent buyer number field and associated
data are stored by the add-on data source 320.
[0037] In order to manipulate data in a particular data source 108,
the object broker process 304 preferably calls methods built into
the associated data source 108. For example, each data source 108
typically includes methods to store/retrieve data to/from the data
source 108 (e.g., the CRM data source may support a "LoadContact"
method as described in detail below). In addition, the system 300
allows a user to author their own functions. For example, a user
may need to apply a discount to certain customers. However, the
existing data sources 108 may not include a method to calculate the
discount. Accordingly, the user may author a "CalcDiscount"
function as described below. User defined functions may use data
from more than one data source 108. The definitions for these user
defined functions is then stored in the function data source
322.
[0038] User defined functions may be created using a graphical user
interface tool. For example, parameters for a user defined function
may be defined by selecting a graphical representation of the
parameter associated with a business object. Preferably, user
defined functions are stored as snippets. Snippets include a
structure portion that defines the function and a user interface
portion that provides the user a way to test the function. For
example, the structure portion may be stored as XML, and the user
interface portion may be stored as HTML in the same file.
[0039] Some user defined functions may be executed by the client
devices 102 thereby reducing communication with the servers 110,
114. Other user defined functions may require server side
execution. Preferably, a determination is made if a particular
function is to be executed on the client side or on the server
side, and an indicator of this determination is stored with the
function snippet. For example, user defined functions built from
certain predefined primitives (e.g., add, multiply, loop, less
than, etc.) may be determined to be executable by the client device
200, while other user defined functions that include database
lookups (e.g., SQL statements) may be determined to be executable
by a server 110, 114.
[0040] From a user's perspective, the data from the data sources
108 (as well as data calculated from data in the data sources 108
e.g., a discount) is viewed using one or more electronic forms 302,
310, 312. In addition, the user may manipulate the data and/or add
data via the electronic forms 302, 310, 312. Forms 302, 310, 312
may be combined into pages 302 and one form may use data from more
than one data source 108. For example, the customer orders page 302
combines the customer contact form 310 and the order list form 312
(as described in detail below with reference to FIG. 5). In
addition, portions of forms and/or entire forms that are part of a
larger page, may be locked so that only certain users can modify
that portion of the form or page.
[0041] In order to facilitate forms 302, 310, 312 that combine data
from different data sources 108, the system 300 employs an object
broker process 304 and a form process 326. In one embodiment, the
object broker process 304 is ASP code running on the object broker
server 114 and the form process 326 is JavaScript running on a
client device 102. The object broker process 304 compiles data in a
variety of different native formats from the different data sources
108 into standardized business objects 306, 308 (e.g., XML files).
In addition, the object broker process 304 accepts the data via the
business objects 306, 308 and stores the data back to the data
sources 108 in the correct native format.
[0042] More specifically, the object broker process 304 uses a
plurality of broker services to communicate with the data sources
108. Preferably, one broker service is used for each data source
108. In this example, the object broker process 304 includes an ERP
broker service 328, a CRM broker service 330, a custom broker
service 332, an add-on broker service 334, and a function broker
service 336. Each broker service 328, 330, 332, 334, 336 is
designed to communicate with the associated data source 108 using
the data source's native formats and protocols.
[0043] Each broker service 328, 330, 332, 334, 336 then
automatically exposes the properties and methods of the associated
data source 108 as standardized properties and methods 338 for use
by the business objects 306, 308. For example, the ERP broker
service 328 communicates with the ERP data source 314 via the
BizTalk server 324 and exposes the ERP data source 314 properties
and methods to the customer business object 306 and the order
business object 308 as XML files. If new properties and/or methods
become available from a data source 108, the associated broker
service preferably detects these new properties and/or methods and
automatically exposes the new properties and/or methods for use by
the business objects 306, 308. The business objects 306, 308 may
include some or all of the exposed properties and methods 338. Each
business object 306, 308 then exposes its included properties and
methods 340 to the form process 326.
[0044] The form process 326 calls business object methods 340 in
response to form events and populates the forms 302, 310, 312 with
data from the business object properties 340. For example, a user
may press a "Load" button on the customer orders page 302, which
causes the form process 326 to call one or more methods 340 exposed
by the business objects 306, 308. This, in turn, causes the object
broker process 304 to retrieve the appropriate data from one or
more data sources 108. The data is then returned as properties of
the business objects 306, 308, and the form process 326 uses the
data to populate the forms 310, 312.
[0045] In addition, the form process 326 may store values to the
business object properties 340, and call methods to have the
new/modified data stored back to the appropriate data source 108
via the object broker process 304. For example, a from may accept a
new value for a customer's address and call an UpdateContact method
to have the new address stored to the appropriate data source 108.
The form allows the user to update the customer's address without
knowledge of the underlying data source 108.
[0046] The form process may 326 may call methods that implement
standard SQL methods such as INSERT, UPDATE, SELECT, DELETE, etc.
The methods act as stored procedures to external interfaces and can
take parameters to manipulate the data resultsets. For example, the
INSERT method may take a number of parameters for the INSERT
operation to execute.
[0047] Additionally, a business object may represent data
associated with a business process. For example, a business process
data surfacing module on the object broker server may create a
business object exposing the business process data as a standard
database construct. The business process data surfacing module may
take a business process and create a business object entity wrapper
encapsulating the business process data as well as business process
objects in a single entity.
[0048] By exposing a business process as a business object with
standard database operations, the business process user is able to
perform functions on the workflow process such as reporting or
building client applications.
[0049] A more detailed block diagram showing these connections
between the example data sources 108 and the example business
objects 306, 308 is illustrated in FIG. 4. In this example, the
customer business object 306 is connected to the ERP data source
314 and the CRM data source 316. The order business object 308 is
connected to the ERP data source 314, the add-on data source 320,
and the function data source 322. These logical connections may be
defined in any suitable manner. For example, a graphical user
interface may be used to allow a user to draw connection lines
between graphical representations of the data sources 108 and
graphical representations of the business objects 306, 308.
[0050] These logical connections are maintained by the object
broker process 304. For example, data to populate the customer
contact form 310 and the order list form 312 may be brought into
the customer business object 306 and the order business object 308
from the data sources 108 by the object broker process 304.
Similarly, new and modified data from the customer contact form 310
and the order list form 312 may be sent from the customer business
object 306 and the order business object 308 to the data sources
108 by the object broker process 304. In addition, the role service
323 may generate a reduced object definition based on these full
object definitions. For example, the role service 323 may retrieve
a role associated with a particular user and a plurality of
authorized properties and/or methods associated with that role.
Unauthorized properties and/or methods are then removed from the
business object definition (e.g., a particular user is not allowed
to write to the customer business object, therefore the
UpdateBalance and UpdateContact methods are removed).
[0051] The example customer business object 306 includes a customer
ID property, a name property, an address property, an outstanding
balance property, a load balance method, an update balance method,
a load contact method, and an update contact method. The customer
ID property in the customer business object 306 is connected to the
customer ID property in the ERP data source 314 and/or the customer
ID property in the CRM data source 316. The name property and the
address property in the customer business object 306 are connected
to the name property and the address property in the CRM data
source 316. The outstanding balance property in the customer
business object 306 is connected to the outstanding balance
property in the ERP data source 314. The load balance method and
the update balance method in the customer business object 306 are
connected to the load balance method and the update balance method
in the ERP data source 314. The load contact method and the update
contact method in the customer business object 306 are connected to
the load contact method and the update contact method in the CRM
data source 316.
[0052] The example order business object 308 includes an order
number property, a customer ID property, a delivery date property,
a tax property, a total property, a status property, a create order
method, a load orders method, an update order method, a delete
order method, a calc discount method, and a calc tax method. The
order number property and the status property in the order business
object 308 are connected to the order number property and the
status property in the ERP data source 314. The customer ID
property in the order business object 308 is connected to the
customer ID property in the ERP data source 314 and/or the customer
ID property in the add-on data source 320. The delivery date
property, tax property, and total property in the order business
object 308 are connected to the delivery date property, tax
property, and total property in the add-on data source 320. The
create order method, load orders method, update orders method, and
delete order method in the order business object 308 are connected
to the create order method, load orders method, update orders
method, and delete order method in the ERP data source 314. The
calc discount method and the calc tax method in the order business
object 308 are connected to the calc discount method and the calc
tax method in the function data source 322. It will be appreciated
that the names of the properties and/or methods in the data sources
108 need not be the same as the corresponding names of the
properties and/or methods in the business objects 306, 308.
[0053] A screenshot of an example process is presented in FIG. 5.
Although the example process is described in reference FIG. 5, it
will be appreciated that many other configurations are possible.
For example, elements could be in different locations, elements
could have different names, and elements could have different
graphical representations.
[0054] Most processes consist of a number of activities and events.
Some events may require input from a user and are called events.
Other events can be executed without any user interaction and are
called server events. Process 500 has three activities, Order
Approval 502, Order Approved 504 and Order Declined 506. Activities
may have associated events. For example, the Order Approval 502
activity has an associated event Approve Order 508. Events are
categorized based on the entity that performs the event, for
example, the Approve Order 508 event is an event.
[0055] Events may have actions. For example, the Approve Order 508
event has actions "Approved" 510 and "Declined" 512. As with
business processes, activities can have data associated with the
scope of that activity. For example, the Approve Order 508 event
may have an "Order ID" that is defined as data at the process
level.
[0056] When a process is deployed, logical business objects
("business entities") may be created for the process itself and for
each event in the process. For example, when deployed, process 500
may have a business object created for the process 500 and for the
Approve Order 508 event.
[0057] A screenshot of an example business object model is
presented in FIG. 6. Although the example business object model is
presented in reference FIG. 6, it will be appreciated that many
other configurations are possible. For example, elements could be
in different locations, elements could have different names, and
elements could have different graphical representations.
[0058] If data is defined on the business process level, that data
may become a property for all business entities (e.g., the process
business object and the event business entities). For example, if
"Order ID" is defined as data on the process level, it may become
an "Order ID" property 606 in the Order Approval Process Business
object 602 and the Approve Order Business object 604, where the
Order Approval Process Business object 602 is associated with the
overall business process and the Approve Order Business object 604
is associated with the Approve Order event 508.
[0059] A screenshot of an example data flow model is presented in
FIG. 7. Although the example data flow model is presented in
reference FIG. 7, it will be appreciated that many other
configurations are possible. For example, elements could be in
different locations, elements could have different names, and
elements could have different graphical representations.
[0060] The data flow may begin with the design process (block 702).
For example, required data may be identified during the initial
design of the business process. The data flow may then continue to
the deploy process (block 704). For example, at runtime the
required data may be determined.
[0061] A business object method may be created for each process
action (block 706). For example, each business process action a
business object method may be created. The Order Approval Process
Business object 602 may have a Start Order Approval method created
for the Start Approval activity, as seen in FIG. 6. For each
process level data field a property of the business object may be
created (block 708). For example, if "Order ID" was set to a
business process level data field, an "Order ID" property may be
created for the business object.
[0062] A business object may be created for each event as well
(block 710). For example, an Approve Order 508 event may have its
own business object created for it. As with the business process
business object, each event action may have a business object
method created (block 712). Each process level data field may be a
business object property (block 714), and each activity level data
field may be a business object property (block 716). For example,
in the Approve Order Business object 604, a process level data
field may be "Order ID" and an activity level data field may be
"Activity Start Date" which is localized to the event business
object.
[0063] A screenshot of an example deployment screen is presented in
FIG. 8. Although the deployment screen is presented in reference
FIG. 8, it will be appreciated that many other configurations are
possible. For example, elements could be in different locations,
elements could have different names, and elements could have
different graphical representations.
[0064] When the process is deployed, the user may be given a choice
to generate business entities during the deployment of the process
or to generate the business entities manually after deployment. For
example, the user may be presented with an option 802 to create the
business object, or "Workflow SmartObject."
[0065] A screenshot of an example workflow screen 900 is presented
in FIG. 9. Although the example workflow screen 900 is described in
reference FIG. 9, it will be appreciated that many other
configurations are possible. For example, elements could be in
different locations, elements could have different names, and
elements could have different graphical representations.
[0066] The workflow screen 900 may contain a workflow object, or a
plurality of workflow objects, such as tasks, events, activities,
etc. The workflow may be stored in the data sources 108.
[0067] A screenshot of an example business entity selection screen
1000 is presented in FIG. 10. Although the example business entity
selection screen 1000 is described in reference FIG. 10, it will be
appreciated that many other configurations are possible. For
example, elements could be in different locations, elements could
have different names, and elements could have different graphical
representations.
[0068] The business entity selection screen 1000 may be based on
workflow processes stored in the data sources 108. The business
entity selection screen 1000 may have a business entity listing
1002. The business entity listing 1002 shows all available business
processes. The business entity selection screen 1000 may also have
a related data window 1004. The related data window shows data from
the business entity that is selected on the business entity listing
1002 as well as any related business entities. For example, a
workflow process, represented as a Business object, may make use of
other business objects as part of the business process. A workflow
process that deals with Customer information may have an associated
business object for a Customer that has read/write interactions
throughout the business process runtime. The associated business
object will also be presented in the related data window 1004 and
be available for reporting and external client application access.
Since all business objects can be represented as standard database
constructs, the business user is not limited to just working with
workflow data.
[0069] A screenshot of an example data selection screen 1100 is
presented in FIG. 11. Although the example data selection screen
1100 is described in reference FIG. 11, it will be appreciated that
many other configurations are possible. For example, elements could
be in different locations, elements could have different names, and
elements could have different graphical representations.
[0070] The data selection screen 1100 allows the user to select
specific data elements to report on. The data selection screen 1100
may include report data listing 1102 and reporting window 1104. By
using the data selection screen 1100, the user can create detailed
reports on the data that the user wishes to monitor. The data
selection screen 1100 provides a front end interface to the
business entities and an interface for performing database
operations on the business entities.
[0071] A screenshot of an example workflow process overview screen
1200 is presented in FIG. 12. Although the example workflow process
overview screen 700 is described in reference FIG. 12, it will be
appreciated that many other configurations are possible. For
example, elements could be in different locations, elements could
have different names, and elements could have different graphical
representations.
[0072] The workflow process overview screen 1200 contains a
workflow process listing 1202. The workflow process listing 1202
shows all of the running processes on an object broker server 114
or another server executing a business process.
[0073] A screenshot of an example process instances report screen
1300 is presented in FIG. 13. Although the example process
instances report screen 1300 is described in reference FIG. 13, it
will be appreciated that many other configurations are possible.
For example, elements could be in different locations, elements
could have different names, and elements could have different
graphical representations.
[0074] The process instances report screen 1300 contains a workflow
instance listing 802. The workflow instance listing 1302 shows all
of the running instances of a given type of business entity. It
will be appreciated that many other reports are possible. For
example, Process and Activity detail reports.
[0075] A screenshot of an example view flow screen 1400 is
presented in FIG. 14. Although the example view flow screen 1400 is
described in reference FIG. 14, it will be appreciated that many
other configurations are possible. For example, elements could be
in different locations, elements could have different names, and
elements could have different graphical representations.
[0076] The view flow screen 1400 includes a workflow process view.
The workflow process view may include colored workflow process
objects 1402 showing completed process steps. The workflow process
view may also include a colored workflow process object 1404
showing the current workflow process step. In this way, the user
can determine where in the process the data is from. The view flow
screen 1400 also allows the user to transition between the
standardized database construct view and the workflow process
view.
[0077] In summary, persons of ordinary skill in the art will
readily appreciate that inventive methods and apparatus related to
automated workflows and forms have been disclosed. The foregoing
description has been presented for the purposes of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the exemplary embodiments disclosed. Many
modifications and variations are possible in light of the above
teachings. It is intended that the scope of the invention be
limited not by this detailed description of examples, but rather by
the claims appended hereto.
* * * * *