Understanding the HCM Interface Registry

The HCM interface registry holds all the interface specifications for available services in the Service Oriented Architecture (SOA). It stores contracts from service providers and provides those contracts to interested service consumers.

The service provider registers the interface, the consumer locates the interface in the registry and uses the information to bind and run the contract between the consumer and the provider, as shown in this diagram:

 The service consumer finds an interface in the registry and the registry provides the information necessary to bind and execute the service

The service consumer is an application, service, or some other type of software module that requires a service. It is the entity that initiates the location of the service in the registry, binding to the service over a transport, and running the service function. The service consumer runs the service by sending it a request formatted according to the contract.

The service provider is the service, the network-addressable entity that accepts and runs the requests from consumers. It can be a mainframe system, a component, or some other type of software system that runs the service request. The service provider publishes its contract in the registry for access by service consumers.

To set up and use an interface registry:

  1. Set up the interface contract and register the interface using the Registration Wizard (Set Up HCM > System Administration > HCM Registry > Registry Wizard).

  2. Implement the interface in the providing application.

  3. Set up the consuming application to invoke registered interfaces.

Setting Up Interface Contracts

An interface contract specifies the way a consumer of a service will interact with the provider of the service, including the format of the request and response from the service. The HCM registry is populated with the existing interface contracts within HCM. To add new interfaces to the registry, you must first define the contract between the services.

To define an agreement between services, follow these steps:

  1. Determine the interface details (such as signature, exceptions, and warnings).

  2. Register the interface under the provider object identifier.

  3. Set the interface status to Active.

Note: Register interfaces using the HCM registry's Registration Wizard.

Interfaces fall into one of the following categories:

  • Services

    • Synchronous request/response (services)

      Services interfaces are procedural invocations and can be local and remote.

    • Asynchronous publish/subscribe (events)

      Events can be notifications (outbound) or consumption (inbound) and are based on messaging and integration points.

  • sqlViews (views)

    Views are read only and are SQL-based.

  • Types

    Types represent the complex data types used in service invocations. The following types are supported for service invocations in API:

    • Primitives (native PeopleCode data types), such as string, date, number, boolean, hexbinary, and arrays.

    • Complex types, as defined in the registry or arrays of any complex type.

    Note: While you can use all primitive types in service invocations natively, all complex types must be explicitly defined and registered in the registry.

  • Exceptions

    Exceptions are fatal errors that can occur during the service run and require special handling by the PeopleCode program. Service providers must identify exceptions that they believe can occur so that the consumer code can manage the exception.

    Define exceptions and register them in the interface registry.