Patent Application
20130250960
The invention generally relates to systems and method for routing service request messages.
The present invention relates to a method, system and non-transitory computer readable medium for routing a service request message. The received service request message includes a payload portion and a context portion. Constituency specific attributes and domain specific attributes of the service request message are identified from the payload portion. Context attributes, a service consumer identity, a service name and a service version are identified from the context portion. A service registry is queried using the service consumer identity, the service name and the service version to identify service metadata. An endpoint address to route the service request message is identified using the one or more constituency specific attributes, the one or more domain specific attributes and the service metadata.
The foregoing summary, as well as the following detailed description of various embodiments, will be better understood when read in conjunction with the appended drawings. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
In the drawings:
A request message for a business service or transaction for a client application can potentially be served by one of the several back end systems of an enterprise. For example, for an enterprise in the health payor industry, such back end systems may relate to membership, eligibility, claim, product, provider, pricer and others. For some enterprises, certain of these backend systems may have multiple instances a serving business or a geographic region. The present invention relates to a routing system that can be implemented within an organization to allow for more efficient routing of messages to appropriate back-end systems. While the invention is described herein with reference to the healthcare payor industry for illustration purposes, it will be understood by those skilled in the art that the claimed invention can be used in other contexts (i.e., with reference to domains other than the healthcare domain model) and is not limited to the healthcare payor industry in particular.
The systems and methodologies described herein provide a comprehensive framework for content-based routing in a federated environment. In routing to the various back end systems, the integration layer, implemented as an Enterprise Service Bus (“ESB”), determines the destination system, or systems in the case of aggregation, by inspecting data fields in a particular domain (e.g., healthcare domain) of the request message content. Matrix routing logic is employed, based on the constituent represented by the requestor (e.g., member, provider, broker etc.) and the domain to which the requested service belongs.
In connection with the systems and methodologies described herein, data field values in the request are evaluated against a set of routing rules to determine the backend system or system that will process the request; routing rules are driven by the metadata stored in persistent stores, e.g., a relational database system; and a software component takes the values of certain fields from the request as input, applies rules based on the metadata in the persistent store, determines backend systems that will process the request, in terms of their logical names, and returns those logical names as output.
In general, the system described herein is comprised of two primary components—(1) a persistent store to store routing metadata and (2) a software implementation of routing logic using the routing metadata. The router may be implemented using a relation database for storing routing metadata and an application server environment, such as J2EE, for implementing the routing logic as software services. The routing services may be exposed with both web services/REST services interfaces and native interfaces. The external systems can choose one type of interface that is the most appropriate. The approach described herein uses a general routing framework to accommodate the different router variations and to support many different constituencies (i.e., business users) and associated domains. The routing logic is wrapped into a utility service for each constituency, which different ESB instances can access. In the healthcare payor context, for example, two such constituencies are Member and Provider.
The system described herein can be used when the service consumer identity along with the service metadata and the context of request are not sufficient to route a request to the right service provider. Additional information from the message payload is needed to determine the target back-end system for the request.
The routing service for the Member constituency, for example, contains a component for each domain to determine the service provider for a request in that domain. The domain specific routing logic is exposed as an operation for the service. The inputs for the domain specific routing for Member constituency are context attributes, service metadata, member attributes and domain specific attributes. The output from the routing logic is one or a set of logical names of service providers in that domain. Note that more than one service provider signifies an aggregation condition. The ESB then finds the appropriate end-point addresses by consulting service meta-data from the registry and repository. The various routing components use a database for to obtain the routing metadata.
The steps involved with routing messages in accordance with the embodiments described herein are illustrated with reference to
Service registry 100 and routing data database 170 may each be comprised of one or more relational databases; however, other data organizational structure may be used without departing from the scope of the present invention. Routing module 120 is a software module comprising computer-readable instructions that are stored in non-transitory memory and executed by a computer processor. The computer processor is therefore specially programmed to implement the functionality described herein.
Exemplary routing attributes for the various domains for a Member constituency are provided in Tables 1 and 2 below. It will be understood by those skilled in the art that the Member constituency, referring to the healthcare payor domain, is shown for illustration purposes only.
Note that the term ‘static’ in the Domain Attributes column signifies that there is a one-to-one relationship between the Membership system and domain-specific system.
The routing logic is illustrated with an example of a service in the claims domain invoked by a Member constituency, as follows. A sample request message is shown below with the key data elements for routing.
The service consumer metadata is retrieved from the service registry based on the service consumer identity in the context part of the message.
The input for the query to Service Registry is:
The output from the query to Service Registry is:
The constituency of the service consumer is determined. In this example, the constituency is ‘Member’.
The domain for the service is determined from the service metadata. This informs the operation that is to be invoked on the routing service for the constituency. In this example, the domain is ‘Claims’.
The constituency and domain-specific routing attributes are extracted from the message payload.
In this example, the constituency attributes from the message are:
In this example, the domain attributes from the message are:
The domain specific routing operation is invoked on the constituency-specific routing service.
The input to the router operation is:
a. Context attributes
b. Service Metadata
c. Constituency-specific attributes
d. Domain-specific attributes
The output from the router operation is:
The returned service provider name(s) is used to determine end-point(s) and the corresponding address(es) from the service provider and the end-point(s) metadata from the service registry.
The input for the query to Service Registry is:
The output from the query to Service Registry is:
The metadata of the service provider endpoint is used to transform the message, if necessary. In this example, Metadata.ESB.Endpoint.messageFormat and Metadata. ServiceProvider.Endpoint.messageFormat are the same format (SOAP), so transformation is not necessary.
The message is then routed using the endpoint address. In this example, the service using is invoked the HTTP URL: ‘https://service.wellpoint.com/fctcr/claims’.
It will be appreciated by those skilled in the art that changes could be made to the examples and various embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular examples and embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.
