Outbound Restful Service Invocations

Introduction

For calling RESTful services provided by other applications or systems or for sending out notification/messages to external RESTful systems, certain features can be set regarding the security, method type, etc. Sample examples could be:

  • Sending requests from one Oracle Health Insurance application to another, e.g. as is the case for Data Replication (to synchronize member data between Oracle Health Insurance Policies and Oracle Health Insurance Authorizations) or to pass Enrollment data between Oracle Health Insurance Claims and Oracle Health Insurance Policies.

  • REST client defined in Call Out Rules that are configured in Dynamic Logic code for accessing services in external applications.

  • Sending notification for activity or a long running process completion.

  • Sending out financial messages etc

The system fetches these properties (described below) on the bases of the use case. The details on the key value (referred to as '{0}') to be used is documented with the function that can send/call outbound services.

Category Property Name Value Explanation Media Type

ohi.service.{0}.media.type

Optional. Example: * ohi.service.ActivityResponseClient.media.type=application/json * ohi.service.<activity_type_code>.media.type=application/xml

The media type in which the response is sent to the external endpoint. Default value is application/json

Http Method

ohi.service.{0}.notification.method

Optional. Possible values are POST or PUT

  • ohi.service.FinancialMessageNotificationClient.notification.method= POST

  • ohi.service.ResendFinancialMessageClient.notification.method= PUT

Controls which HTTP Method to use to send out the notification. Default is POST

Authentication Mechanism

The system requires additional configuration to be in place if the Authentication mechanism is set to Basic Authentiona or OAuth. For more details, refer to chapter 'Securing Outbound RESTful service invocation' in the guide.

Outbound Notifications

The system requires a 'correlationId' header parameter in the request, which sent in for starting a long-running process to correlate it with the notification that gets out once the process concludes. If the request contains this header parameter, then the respective notification also contains the same value.

The notification structure has the following structure.

<notification correlationId="" workId="{workId}" status="Success/Failure">
  <links>
    <link rel='messages' href='<link to download messages if any produced by the operation>'/>
    <link rel='self' uri='<link to the operator>'/>
    <link rel='file' uri='<link to the files that got generated>'/> ...
  </links>
</notification>