HR-XML 3.0 Standards, 2009 September 23.
Menu: [ Home | Guidelines | BODs | Nouns | Global elements | WSDL | Packages | Code Lists | Master Index ]
Trace back: » ch05 | ch28 | ch06 | ch40 | ch01 »
Table of Contents
The sections below introduce key concepts associated with HR Interoperability standards. The intention here is to present concepts concisely using simple language within an HR systems context. Note that several standards organizations have developed far more complete ontologies or meta models relating to service oriented architecture (see the section called “Other Resources”).
HR-XML standards are principally concerned with defining messages communicated between and among software components.
Messages specify a behavior to be performed on, or a state to be associated with, an object. For this reason, messages tend to be named using a "verb-noun" construction. For example, ProcessPositionOpening (with "Process" being the verb and "Position Opening" being the noun).
Messages can be used to invoke services and also can be a response from such invocation. In other words, a message may be a service input as well as a service output.
"Canonical messages" are formally modeled messages intended to be reused broadly across an enterprise or among trading partners. These messages are "canonical" in that they define a single way to convey specific type of information or intention. Canonical messages are derived from a Canonical data model.
Messages can be communicated using a variety of protocols, both standard and proprietary. Web services typically communicate messages using SOAP and HTTP. An Enterprise Service Bus (ESB) is an example of proprietary messaging technology used to carry messages among enterprise services. HR-XML standards are transport neutral so that they might be used under a variety of transport mechanisms.
While a primary focus of the current HR-XML library is a message-oriented model and SOAP-style Web services, other software architecture approaches also might be supported by the HR-XML data model (for example, "Resource Representational state transfer" or so-called "RESTful" approaches).
A Business Object Document (BOD) is a message constructed according to the methodologies of the Open Applications Group. BODs provide a high level of re-use. By making available a consistent messaging meta model across diverse business domains, BODs provide a faster learning curve for developers, business analysts, and integrators.
BODs encapsulate both behavior and structure for business interactions and facilitate data management among system actors. The major components of a BOD are depicted in the diagram below.
For a full explanation of BODs and their components, see the section called “Business Object Documents”.
Data management refers to procedures and policies that trading partners use to communicate new and updated information between them so each can maintain an accurate account of the entities that are the subject of the collaborations. More specifically, data management is used as an umbrella term to refer to Create, Read, Update, and Delete (CRUD) operations performed on managed entities using the OAGIS business object document (BOD) architecture. HR-XML's data management guidelines are a subset of those drafted by the Open Applications Group. For further information see Chapter 2, Data Management.
An actor is a person, an organization, or a system (a "system actor").
Actors can be providers and/or consumers of services or otherwise have a role in triggering collaborations between service providers and consumers.
The Actor Catalogue identifies and defines actors commonly involved in HR business processes covered by the HR-XML standards.
HR-XML standards typically are concerned with enabling collaborations between and among arm-length trading partners. In other words, the standards are primarily designed around business-to-business communications. To a lesser extent, HR-XML standards are used within application-to-application integration scenarios where system actors are within the same organization.
For further information, see Chapter 42, Actor Catalogue.
A business event ontology is a reasonably complete collection of business events definitions that represent the points within business processes where collaborations between actors occur.
Events trigger changes in the state of business objects and related communications between actors.
Events relevant to HR collaborations can be broadly categorized as: 1. personal (for example, an employee change of address, marriage, divorce, disability, etc.); 2. employment and work-related (hire, termination, promotion, etc.); and 3. organizational (merger, acquisition; plant closing; bankruptcy; policy changes; vendor changes; etc.). Events also can be fine-grain, process-specific occurrences (for example, successful completion of employment screening may clear the way for a next step or stage of a hiring process).
HR-XML standards commonly refer to both course-grain event categories (for example, personal information changes) as well as fine grain events (change of a home postal address).
There can be relationships and priorities among different events. One event may trigger another. Likewise, the occurrence of a certain event may supersede another as a trigger for a collaboration.
An "event driven architecture" is a style of application and system architecture characterized by a set of relatively independent actors working towards coordinated goals by communicating and responding in predictable ways on the basis of event triggers.
For further information, see Chapter 44, Event Catalogue.
Scenarios are intended to provide guidance for implementers in understanding how to apply HR-XML standards.
A scenario is a generalized representation of a business collaboration. Scenarios identify and describe things such as:
A business purpose or "use case" (or use cases).
A collaboration among actors to fulfill such use cases.
The actors involved in the collaboration.
Events that trigger the collaboration(s) between and among Actors.
Preconditions or requisites for the collaboration.
Error and success cases (so called "Post Conditions").
Variations in how the collaboration occurs or is carried out.
A scenario is realized through a collaboration between trading partners using appropriate "service compositions".
A service composition is a collection of services (one or more services) organized in a way so as to fulfill one or more use cases.
In many collaborations, each trading partner will have its own service composition to fulfill a collaboration between or among the trading partners. For example, in an assessment procurement collaboration an Assessment supplier may host services that a customer or requester may call (ProcessAssessmentOrder, GetAssessmentReport). Likewise, a customer or requester may host services to support its part of the collaboration (for example, a NotifyAssessmentReport service that the supplier may call to push an assessment result back when one comes available).
In the HR-XML library, certain "packages" are available to support service compositions for a particular trading-partner role. For example, AssessmentOrder_SupplierPackage is intended to support order services that the Assessment Supplier would host. A corresponding AssessmentReport_RequesterPackage is intended to support services that the Assessment Customer or Requester would support -- such as a service the Supplier could call to notify the Customer/Requester of a result.
Note
HR-XML packages currently are specified using a very simple request-response message exchange pattern (MEP). This type of MEP most clearly represents the business intentions associated with message exchange. However, services may be designed with many different MEP approaches based on the business requirements associated with particular implementations. Thus, the packages provided within the library are intended as illustrative starting points for service compositions customized around the particular requirements of trading partners.
These packages include the necessary schemas flattened into a normalized, "runtime" schema package that brings in only required data types from developer schemas. The schemas also include a related WSDL for each service composition.
A profile is a specification based on an HR-XML BOD schema that qualifies or constrains the complete schema to fit a particular business scenario, pattern of implementation, or trading partner implementation. Part or all of a profile can be tested in an automated manner. Examples of possible profiles are:
Candidate Profile. HR-XML's Candidate Schema can be used to support such diverse use cases as Resume Parsing and Candidate submission from job boards and staffing agencies. Profiles could be developed to support one or more of these uses or a particular implemention of the schemas within those use case categories.
Screening Order Profile. Three implementation patterns have been recognized in using HR-XML screening schemas. These so-called "Package Only", "a la Carte", and "Package Plus" patterns are explained in the related documentation. Again, profiles could be developed to support one or more of these broad use patterns or a particular implementer's pattern of use.
A "code" is a character string (letters, figures or symbols) that for brevity, language independence, or trading-partner neutrality may be used to represent or replace a definitive value or text of a property. Codes usually serve the purpose of "classifying" the associated entity. Note that this is separate from "identification," which is handled by an identifier type. Broadly speaking, HR-XML's version 3.0 architecture recognizes three types of code lists:
External. As the name implies, external code lists are not enumerated within the HR-XML library. The core component CodeType provides the meta data to optionally reference the particular code list (using the "listID" attribute) and the agency or company that controls that list (listAgencyID). External code lists typically are either well-known, official, "standard" code lists for the particular value domain that are controlled and maintained by a recognized authority or in other cases, these lists may be proprietary and controlled by a particular trading partner or business.
Open. Open lists have values that are specified within the HR-XML library (see \OAGi-BPI-Platform\org_hr-xml\3_0\Developer\Common\CodeLists.xsd). However, these values are defined in a way so they are not enforced by HR-XML schemas. Other values may be specified. In other words, open lists can be extended simply by using alternate values than those enumerated within the HR-XML library. Essentially, open lists provide documentation of suggested values. Working groups or trading partners might set certain business rules regarding the use of open lists apart from what is enforced within the schema (see the section called “Profiles”.
Closed. These are lists HR-XML develops and maintains. A closed list implies that the list will be implemented without restriction or extension. Note that most code lists within the HR-XML library are defined as open lists rather than closed lists.