This invention relates to service-oriented computer architectures and systems for business process management.
In the human resources area of corporations, numerous situations exist in which employee information and data needs to be created, entered, accessed, or modified. For example, employees enroll in or change health plans, require changes to their family or other personal information, and become eligible for different programs. Administrators, managers, and employees need to create, enter, access, and review personnel data, compensation data, and other information.
The information may exist in different formats within numerous databases having different structures. Software programs for accessing the information may require different structures and formats. Different individuals may have differing rights to create, enter, view, or change the information, and different information may require different levels of confidentiality.
These conditions make it difficult to provide an effective system for providing different company personnel with the appropriate tools for creating, entering, accessing, and manipulating this information in an integrated manner.
A service-oriented architecture includes applications, business services, business functions, and data repositories for developing and deploying human resource or other applications. Applications correspond to a set of processes, and may include a graphical user interface. The applications access business functions within business services. The business functions provide mechanisms for accessing and processing data.
Applications may access business functions directly or through an interface that provides a common format for accessing the business functions. In some embodiments, the business functions access data through components that provide data transformation and mapping so that the business functions may be independent of the data format.
In some embodiments, the architecture uses open standards and common tools and protocols, such as Java and XML, and provides flexibility to develop, deploy, configure, and customize the applications, services, and functions. The applications may be web-based. The architecture allows the additions of functions without affecting applications.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
Referring to
In some embodiments, internal applications 110 are web-based, written in Java, and built using Struts and Applet technology. Other technologies also may be used. Site controller 115 manages web flow. External applications 180 may be constructed with any computer language and architecture.
Applications include internal applications 110 and external applications 180. Internal applications 110 request processing from and interact directly with business services 120 and business functions (which are described below). In some embodiments, communication between internal applications 110 and business services and business functions occurs using data in an XML format.
External applications 180 may, for example, be legacy or other applications, which access the business services and business functions through a communication protocol and dispatch component, such as web services component 190. Internal applications 110, by contrast, access the business services and business functions directly. Web services component 190 checks requests from external applications 180 and formats those requests into the XML (or other appropriate format) required to access the business services and business functions. Going in the other direction, web services component 190 formats responses in a consistent XML format. Web services component 190 does not need to know the type of application receiving the data.
Business services 120 are collections of business functions, and may be organized to relate to the business domain rather than the database format in which the underlying data exists. The business services also, in some embodiments, provide housekeeping functions, such as configuration settings relevant to the service, or the collection of business functions provided by the service. Business functions provide the processing steps within a business service.
An exemplary catalog of business services and respective business functions is depicted generally at 800 in
In some embodiments, a business service includes a set of business functions common to many or all of the business services. For example, a “business function catalog” function lists business functions accessible through the selected service, filtered by permission and including the Business Object Document (BOD) schemas used to communicate information. The BOD for this function could be, for example, GetListBusinessFunction. Business services also may include, for example, business functions that are common only to one or a few business services.
In a human resources administrative service, functions available to authorized HR administrators may include, in some embodiments, a maintain employees function, to read and update data associated with an employee; a maintain groups function, to create and update group hierarchies; a maintain roles function, to create and update role hierarchies; a maintain memberships function, to assign memberships to roles and groups; and a manage permissions function, to manage permissions associated with role and group hierarchies. BODs associated with this last function, for example, can include: GetPermission, GetListPermission, CreatePermission, UpdatePermission, GrantGroupPermission, RevokeGroupPermission, GrantRolePermission, RevokeRolePermission.
In a managerial business service, functions may include, in some embodiments, a manage proxies function, to track authority delegated by a manager to act on his behalf for a period of time; a manage reporting hierarchies function, to review and make certain changes to reporting hierarchies; a detail reports function, to obtain detailed information for a manager's direct and indirect reports; a rollup reports function, to obtain rollup summary information for a manager's direct and indirect reports; a get employee history function, to access an employee's work history; and a manage workforce events function, to initiate and process workforce events requiring an approval process (including, for example, a job change, an organization transfer, a status change, separation, and a compensation change).
In a payroll business service for processing pay-related requests for employees, functions may include, in some embodiments, a process W4 function, to retrieve the current W4 form and process new and updated W4 forms; a process direct deposit function, to retrieve direct deposit information and update it; and a get pay history function, to retrieve pay records.
In a compensation service, functions may include, in some embodiments, an analyze compensation function, to calculate what-if scenarios based on compensation parameters, and to obtain summary compensation information; and a plan administration function, to create and administer plans, programs, elements and other compensation-related artifacts to support planning.
In a benefits service, functions may include, in some embodiments, a maintain beneficiaries function, to maintain the list of employee beneficiaries; and a maintain dependents function, to maintain the list of dependents and related benefit elections.
In a communications service for handling corporate communications to the workforce, functions may include, in some embodiments, a process surveys function, to manage surveys and associated survey responses. BODs involved in this function can include, for example, AddSurvey, UpdateSurvey, GetSurvey, GetListSurvey, CancelSurvey, GetCatalog, GetSurveyResponse, GetSurveyResponseData, and UpdateSurveyResponse.
In a corporate service for managing corporate-wide information typically readable by anyone (but where returned data can be filtered based on permissions of the caller), functions may include, in some embodiments, an employee directory function, to retrieve selected information about employees, filtered based on permissions; a job directory function, to retrieve selected information about jobs; an organization directory, to retrieve selected information about organizations; a location directory, to retrieve selected information about locations; and an employee groups directory, to create, query, and optionally persist employee groups based on visible attributes of accessible employees.
In a worklist service for individuals to access their list of work items, and other authorized persons to access work items across various subjects, functions may include, in some embodiments, a manage worklist function, to access work items for update or to recall.
In a self service business service, for employees to access information that the employee controls or information directed to the specific employee, functions may include, in some embodiments, a maintain employees function, to retrieve and change parts of an employee's own data that the employee is authorized to change; and a people on file function, to retrieve all individuals referenced in an employee's records, for example, contacts, dependents, and beneficiaries.
A security service may include, in some embodiments, a manage users function, to manage credentials and test login authorization. BODs related to this function may, for example, include UpdateUser, ProcessLogin, and CancelLogin.
In a budget business service, functions may include, in some embodiments, a budget administration function, to create budget numbers, splits, and rollups for use in compensation planning and other events requiring budgets; and a budget monitoring function, to analyze the effects of changing budget allocations and distributions.
In a reporting service, functions may include, in some embodiments, a report directory function, to access available reports; a report targeting function, to associate reports with events, processes, steps, or activities; and a report scheduling function, to schedule reports and maintain the queue.
In an integration business service for providing information transfer management, functions may include, in some embodiments, a subscription management function, to subscribe to information feeds based on events; an outbound queue management function, to manage the outbound Enterprise Resource Planning (ERP) queues; and an inbound queue management function, to manage input queues, frequencies, and policies from System of Record (SOR) and other data sources.
In a hierarchy service, functions may include, in some embodiments, an employee hierarchies function, to maintain a hierarchical grouping of employees; and a position hierarchies function, to control hierarchy of positions.
In a business process service for processing management functions for the system, functions may include, in some embodiments, a process definition, to define processes as steps, transitions, activities, events, and agents; and a process control function, to monitor and manage business processes.
In a performance management business service for providing task records and performance review functions, functions may include, in some embodiments, a goal management function, to manage goals and create links to other goals; and a performance ratings function, to create and maintain organizational and individual performance ratings.
Referring to
In some embodiments, business services 120 encapsulate business logic using an extensible XML-based domain model. Business services 120 provide implementations of common business functionality to be shared among applications and made available through one or more communication protocol and dispatch components, of which the web services component is an example.
The business services access data through data access components 150. Data access components (“DACs”) form a data persistence framework that serves to insulate the business functions from the details of data transformation and mapping. They allow the system to perform, for example, create, read, update, and delete operations on the data. Persistence mapping and data store-specific details are encapsulated in the framework of data access components. Business functions use DACs to retrieve and persist objects in a data store. In some embodiments, DACs primarily represent access to a single domain object—a “noun” or “component”—and have XML schema-based interfaces. In some embodiments, DAC interfaces will not change when a new implementation is necessary for a change in the data store format. This insulates business services and functions from change and decouples the domain object schemas from a particular data store's details. DACs may be implemented by building XML documents from SQL/JDBC (Structured Query Language/Java DataBase Connectivity) result sets.
In order to perform their tasks, business functions in some embodiments interact with one or more DACs or other business functions, combining and/or dissecting their XML documents as necessary. The Data Access Component interfaces represent access to nouns and provide persistence to the databases. To use a different data source, a user may implement the DAC interfaces whose objects are persisted in the new back-end source.
Publishing service 160 allows business services 120 to be configured to publish (e.g., as XML) any changes to data that occur while using internal applications 110 or external applications 180. Publishing service 160 provides data but in some embodiments does not require confirmation of receipt by the receiving module. Publishing service 160 can function similarly to a business service, preserving the data in a BOD format and returning data to a queue. In some embodiments, publishing service 160 is able to push the data (e.g., to a queue) regardless of the noun, and to feed data in near real-time. In some embodiments, the publishing service is configured using a true/false logic state to publish (or not) all data traveling to a data repository.
The data itself are maintained in repository 170. In some embodiments, all or some of the data are provided within repository 170 in a format that allows them to be published to the applications without using publishing service 160. Repository 170 may also include configuration data.
At a lower level, the architecture includes the underlying operating system, an application server, and in some embodiments the Java Virtual Machine (JVM).
In some embodiments, applications and business services communicate using an XML Schema protocol that is based on Open Applications Group Integration Specification 8.0 (“OAGIS 8.0”) and HR-XML standards. Referring to
Business object document 300 includes an application area 330 for identifying the sender and a data area 340 that defines the business operation. Application area 330 contains information that is used to communicate the message, e.g., information that identifies the sender, a time stamp, and unique document identification. The sender information can identify the sender by full credentials or by identity token, and may include proxy information. With both requests and responses, data area 340 carries the business specific payload or data being communicated by the BOD. Data area 340 includes a verb 310, which can be an XML fragment, that represents the action requested, and one or more nouns 320, which are the business object or objects (or other structures) to act upon. In some embodiments, the verbs that BOD 300 may use are a subset of those verbs defined in OAGIS, plus some verbs—such as “Approve,” “Reject,” and “Recall” in a human resource domain—that are specific to the domain.
Nouns carry information that is acted on by the verb in a BOD. In cases where a complex process is being initiated, the noun may represent information to start the process, and the verb may be “Process”. In some cases, the noun relates directly to a business document that is a familiar part of the domain, in which case the verbs that apply are ones that deal directly with document exchange (e.g., Create, Add, Cancel, etc.). Some nouns designate a business entity that is to be manipulated, such as Employee, Group, and Role, and are used with verbs that maintain that entity (Create, Get, Update, Delete). Nouns also can describe, for example, business process specific data, such as WorkforceEvent, Requisition, or PurchaseOrder; or associations, such as Membership, ProxyAssignment, or Permission. BODs can contain more than one noun, which in some embodiments must be of the same type (e.g., a request BOD may have two nouns that represent a requested range or multiple nouns in a batch-type request). Nouns can be added with each new application or business service as it is developed. In some embodiments, nouns include, for example:
The general description of each verb is made concrete when applied to a specific noun. Verbs used with the above nouns include:
Nouns 320 include components 350. Components 350 are extensible building blocks for nouns, and are themselves comprised of compounds 360 and fields 370. For example, “Address” may be a component.
Compounds 360 are the basic, shared building blocks that are used by BODs (e.g., quantity or amounts), and are extensible through contextual use. Fields 370 are the lowest level element defined in OAGIS. Fields are used to create compounds and components (e.g., “Description” or “Name”).
An example of a business object document is shown in
Verb 440 communicates to a business software component a request for an existing piece of information to be returned. The “Lookup” verb can be paired with most nouns. The response to a “Lookup” request is the “Show” verb. The behavior of a BOD with a Lookup verb is predictable across most of the nouns with which it can be paired. “Lookup” is designed to retrieve a single piece of information by using that information's primary retrieval field, i.e., the key field, which for verb 440 is “Dependents.” The Lookup verb is not used to request several documents at once. The LookupList verb is used to return as many matches as are designated. Verb 440 includes return criteria 442 and lookup criteria 444. Return criteria 442 allows the initiator of the BOD to indicate the information, down to the field level, that is requested to be returned. Lookup criteria 444 is an element containing the BOD-specific lookup criteria that is not captured in “Lookup” and “LookupList” requests. For example, Lookup criteria 444 has additional, noun specific criteria used to identify the specific result desired.
Noun 450 includes components employee 452, last updated 454, and dependent 456. Components 452 and 456 are also nouns. Component 454 (last updated) is a field indicating when the information was last updated. Dependent component 456 includes entity 460, containing person data, as well as employee component 482, benefit component 484, relationship component 486, and user area component 488. Entity 460 includes ID field 462, social security number field 464, name component 466, address component 468, sex field 470, birth date field 472, marital status field 474, deceased date 476, and “is disabled” field 478. As this example illustrates, fields can include numerical information, textual information, a date, Boolean data (such as “is disabled” field 478), or other information.
Two examples of response business object documents are shown in
Response BOD 610, “ShowWorkforceEvent,” may be used to respond to a “Get Workforce Event” BOD requesting information on a particular workforce event. A workforce event could be, for example, compensation change, promotion or job change, organizational transfer, status change, and separation. BOD 610 includes application area 620 and data area 630. Data area 630 includes verb 640, in this example indicating the action is “Show,” and noun 650, “WorkforceEvent.” Noun 650 includes ID field 652 that contains a unique identifier for the workforce event, name field 654 that contains a common name for the workforce event, initiator component 656 that contains the name of the user (i.e., the manager or his designated proxy) who initiates and submits the event, initiated date field 658, subject component 660 that contains the employee that is the subject of the workforce event, reason component 662 that contains a code recognizable by the system to describe the action to be taken with the employee, effective date field 664, transaction component 666 that contains one or more transactions to update parts of an employee record, workflow component 668 that, if enabled, holds information specific to the workflow instance, subordinate event component 669 that, when the workforce event can trigger another workforce event, contains details of the subordinate events, comment field 670, alert flag component 672 that indicates the workforce event contains transaction data that violates a business rule and may require an extra level of approval, and user area component 674.
Business services are invoked in some embodiments with business object documents, expressed in XML, that specify a request for information or for the service to take some action. The document sent to a business service indicates the action to be executed, along with the related domain and ancillary data required to perform the action.
Business services 120 and their business functions may be implemented as Java classes, providing a method for each BOD type supported. In some embodiments, all business methods accept an XML document conforming to the BOD schema.
Generally, for each BOD request verb type there is a corresponding response verb type. Pairing these request-response verbs with a noun type defines a business service method. For example, the “lookup” and “get” request type verbs may be paired with the “show” response type verb. In embodiments using XML, for example, a lookupDependents business service method accepts an XML document conforming to the LookupDependents schema and responds with an XML document conforming to the ShowDependents schema.
The signature for this method in the Java business service may be in the form:
The “doc” parameter could contain an instance of the LookupDependents schema that may have the form:
The above example illustrates a request “looking up” the dependents for the employee with ID “007.” The response document may have the form:
An example of the use of BODs to access a business function is shown in
In this example, “BusinessService” corresponds to the name of the business service and “function Method” corresponds to the name of the business function within the named business service. Applications may have graphical user interfaces, and applications are constructed to allow for the runtime or dynamic determination of the nouns and verbs used within a BOD for a call to a business service.
Application 710 passes request BOD 720 to business service 730 in step 740. Business function 750 uses the verb and noun from the BOD to perform the requested action, and then generates response BOD 725 by selecting a response verb and a noun. Business service 730 returns response BOD 725 to internal application 710 in step 760. Internal application 710 can display, forward, and/or otherwise process the returned data. Alternatively, or in addition, the application can make another function call to a business service, with the subsequent function call optionally using some or all of the returned data. For example, request BOD 720 may instruct business function 750 to look up dependents data for a particular employee, identified by social security number, name, or some other identification number. Response BOD 725 may provide the requested dependents information to the application, where it may be displayed.
Referring to
An exemplary internal application is “Organization Transfer,” when an employee is transferred to another manager, organization, and/or location. In some embodiments, upon execution, the Organization Transfer application generally proceeds through the following steps. The following description of steps for the Organization Transfer application is illustrative. Other sequences of steps and other specific technologies may be substituted as appropriate.
First, the application user selects an employee (or subject) and the event to apply to the subject (which may involve another application).
Next, the application user selects an event reason, which explains why the event is needed. To permit the user to select an event reason, the application retrieves the subject from the context of the session and retrieves event reasons. Then, business rules that relate to search constraints are retrieved and applied. The application forwards this information to a Java Server Page (JSP) for display, which permits the user to select a reason.
The selected event reason is saved in the session until the event is committed. Event reasons can be stacked, permitting multiple reasons to be entered. Each reason has a subsequent search screen, to find the new target manager, organization, and/or location. The user enters the relevant criteria in the search screen and submits them.
The application performs some input validation. If no errors are identified, the application creates a Business Object Document (BOD) object. The application (through an Action class) then invokes the Corporate Service business service, which looks up the application-specific Enterprise JavaBeans (EJB) Business Service Function and calls the specific business method, passing the BOD. The EJB Business Service Function breaks the BOD into a Noun and a Verb, invokes the EJB Data Access Component (DAC), and passes the Verb and Noun to a lookupList method, which parses the XML within the Verb and Noun, and forms a database query (e.g., a SQL query) from them. The DAC then executes the query. Alternatively, servlets or other technology could be used in place of the EJBs.
From the records returned from the query, the DAC builds Nouns and returns them to the Business Function. The Business Function creates a response BOD, adds the Nouns to it and returns to the Corporate Service, which then returns it to the application. The application pulls the list of Nouns out of the XML document and breaks the data into chunks to be displayed in the JSP. Control is forwarded to the JSP to display the results.
The user then selects the appropriate item from the search screen and then moves to an “Effective Date” screen, to specify when the event will become effective. The date is saved until the event is committed, and the application then displays a Confirmation screen. The confirmation screen displays the subject's state before the event and the state after the event is committed, at which point the user can confirm (submit) the event.
The application then builds a workforceEvent document containing the data and invokes the Managerial Service business service. The Managerial Service invokes the Manage Workforce Events business function. This business function inserts an event into an Event database table and invokes the Workflow Service (from the Platform Services). The Workflow Service creates a workflow process instance and returns a process instance ID and AcknowledgeVerb, stating that the event has completed successfully.
An Acknowledgement screen then is displayed to the user and the workforce event is complete.
In some embodiments, each business function is associated with a particular business service. An application may call multiple business services and/or multiple business functions within a particular business service.
Business functions may be added to a business service without changing the rest of the business functions grouped under that business service, by making the particular business function name known to the application. Calls to the pre-existing functions remain unchanged.
The code for a business function also may be changed without affecting other parts of the system. The call to the business function will remain the same, so the application is not affected.
At a lower level, if for example a particular noun is changed, then the noun is changed for all functions that use that noun because there is a common definition of that noun for all functions.
The present invention may be implemented in a variety of forms, using software and/or firmware, running on one or more processors for a computing system. The code can be provided in any machine-readable medium, including magnetic or optical disk, or in memory. In some embodiments, the system uses J2EE-based application servers, such as BEA WebLogic or IBM WebSphere application servers; a Crystal reporting server; a relational database (such as an Oracle database); and web servers (which may, for example, be based on open source or proprietary systems).
While there have been shown and described examples of the present invention, it will be readily apparent to those skilled in the art that various changes and modifications may be made without departing from the scope of the invention as defined by the following claims. Accordingly, the invention is limited only by the following claims and equivalents thereto.