HR-XML 3.0 Standards, 2009 September 23.
Menu: [ Home | Guidelines | BODs | Nouns | Global elements | WSDL | Packages | Code Lists | Master Index ]
Trace back: » ch01 | ch07 | ix01 | ch46 | pr01 »
Copyright 2009 HR-XML Consortium, Inc. and its Licensors:
Copyright (c) 1997-2009 Open Applications Group, Inc. All Rights Reserved (License)
See licenses included within distribution file.
The HR-XML 3.0 Standard is HR-XML Consortium's first major release since 2002.
The HR-XML 3.0 library takes the specialized HR domain knowledge contributed to the HR-XML Consortium over 9 years and puts those contributions within a uniform architecture based on the Open Applications Group Integration Specification (OAGIS). OAGIS is the World's most widely implemented XML language for horizontal business functions, such as supply chain management, general ledger operations, and manufacturing. The HR-XML library is the first vertical industry standard to be designed as a plug-in to the Open Applications Group Business Process Integration Platform. You'll notice that included within the HR-XML 3.0 distribution package is the OAGIS BPI Platform Version 1.1. If you are an implementer of OAGIS 9.4 you may be able to install the HR-XML library plug-in, directly with your existing OAGIS installation.
The result of the ambitious HR-XML 3.0 project is a library of specifications for the integration of HR services that is extremely comprehensive, yet is designed to offer developers, business analysts, and integrators faster ramp-up and implementation times.
Chances are that your integration interests focus on just a few of the integration scenarios covered within the specification library. A good way to get started is to browse the scenario descriptions within your particular areas of interest. A master table of contents and index are available to find the related documentation. A compact list of the major documentation sections is provided in the section called “Quick Links”. Starting with example instances also is a common way implementers get up to speed. A trivial "Hello World" example is available to give you a quick idea of how the OAGIS-based architecture works. Look toward the bottom of the master table of contents for a list of dozens of illustrative examples across the range of HR process sub-domains covered by HR-XML.
After surveying the scenario descriptions and examples, it is recommended that you spend some time reviewing the documentation about the new architecture. If you are not already familiar with the OAGIS architecture, you'll want to read enough to have an understanding of Business Object Documents (BODs) and how BOD constructs can be used in data management between and among trading partners. A good introduction to the BOD architecture can be found in Part I, “Architecture and Technical Foundation”.
Feedback forms are integrated into the on-line version of this documentation. You may also direct questions or comments to info@hr-xml.org.
The HR-XML library can be leveraged in a variety of ways to meet a variety of needs. Below are some of the key assets available in the library:
Packages. Many implementers are looking to fulfill a discrete integration need between arms-length trading partners. For example, a business may want to implement a simple web service to accept orders or postings or to sync data with trading partners. Such implementers may first want to examine whether any of the library "packages" are suitable. Packages are built by applying a flattening process to a collection of "Developer BODs" (see description, below). Packages include two or more BODs necessary to support a given integration scenario. The separate Developer BODs are combined and reconciled within a single schema document. Separate files for imported namespaces are still required and are included within each package. An accompanying web services definition language (WSDL) file is provided as a template or starting point for further customization. The WSDL within the packages present simple, request-response style operations, which may or may not be appropriate for your particular implementation. Guidance on other message exchange patterns and WSDL design approaches will be added to future versions of these guidelines. Packages are suitable for run-time validation. Developers also may experience better results in using the packages as the basis for code generation.
Standalone BODs. Standalone schemas are "flattened" versions of individual BODs. Standalone schemas are suitable for such purposes as run-time validation. Like the Packages, developers wanting to generate classes from XML schema often will find they have better results and fewer complications starting with the Standalone schemas versus the Developer schemas. The capabilities and characteristics of developer tools vary significantly. Use of the Standalone schemas may not be suitable for certain types of code generation within certain tools. For example, some tools will encounter problems when trying to generate classes from a WSDL that references two or more Standalone BODs. In such cases, the developer may encounter errors or warnings regarding creation of duplicate classes. Different tools have different tolerances and capabilities in terms of handling such duplicate classes.
Developer BODs. Developer BODs primarily have utility at "design-time." They are constructed in a modular way to maximize reuse of library components. Developer BODs include all globally declared library components. This means they include many more components than actually instantiated or referenced within the BOD iteself. For this reason, Developer BODs generally are not used for run-time validation. Moreover, in most cases, the aforementioned "Packages" and "Standalone BODs" would be better choices than the Developer BODs for uses such as code generation.