8 Set Up Gatekeepers

Set Up Gatekeeper Rules

Here's why you must set up and how you can set up gatekeeper rules in this application.

You set up gatekeeper rules to route requests as well as to filter and publish events specific to given API resources. Setting up gatekeeper rules also ensures that only the events generated by gatekeepers are published to event listeners. These events aren't republished to the gatekeeper which generated them. This avoids duplication of events in the application. For example, if you use Oracle Customer Data Management as the customer master and an Oracle Siebel application for account management, Customer Data Management is set as the gatekeeper. In this scenario, the TMF FA Adapter publishes the account event generated by Customer Data Management to Care Experience. This can lead to creation of the same account in the Siebel application but that application can't republish the account event to Customer Data Management.

By default, an internal application is set as the gatekeeper. You can also set an external application as a gatekeeper. To set the application as a gatekeeper, you must update the gatekeeper rule generated for that application by using the Gatekeeping Rules API. If your new gatekeeper can publish events only for some resources, the existing gatekeeper coexists with the new gatekeeper and continues to publish events for remaining resources.

You can assign multiple gatekeepers for a specific combination of API name, API version, and API resource. If you use multiple applications for managing account or customer data, you must assign one of those applications as the gatekeeper. For example, for the Customer Management API, you can set the Oracle Fusion application to publish events for resources R1 and R2 and your Buying Experience application to publish events for resources R3 and R4.

When multiple gatekeepers are defined for a specific combination of API name, API version, and API resource, the application applies the gatekeeper rules based on the criteria and rank defined in those rules.

How to View Gatekeeper Rules

An empty gatekeeper rule is automatically generated when you integrate your application. The associated API uses this rule to publish the events to event listeners.

Note:

You can't create or delete these rules. You can only update them. These rules are generated based on the details that you provided during integration.

To view the gatekeeper rule for a specific application, call the gatekeeping Rules API by running this cURL command or by using a REST API client:

curl -H Authorization: Bearer <accessToken> https://<hostName>/admin/gatekeepingRules/{id} -X GET

The API returns the gatekeeper rule generated for the specified ID.

To view all the gatekeeper rules, call the gatekeeping Rules API by running this cURL command or by using a REST API client:

curl -H Authorization: Bearer <accessToken> https://<hostName>/admin/gatekeepingRules/ -X GET

The API returns a list of gatekeeper rules generated for all the applications.

Update Gatekeeper Rules

Here's how you can update gatekeeper rules:
  1. Create a payload with the details described in this table. You can create this payload by copying the existing gatekeeper rule generated for the application.

    Note:

    • The application automatically populates the Endpoint Name and Rule Name fields with the values from the system and connection details you provided.
    • For internal applications, you can only update the API resources. For external applications, you can update all the fields as applicable. However, if you make any changes in this rule, ensure that you update the corresponding system and connection details. To update system or connection details, see the Integrate External Applications chapter in this guide.
    • If you are using a custom non-TMF API in a gatekeeper rule, you must provide the Destination Selection details.

    Table 8-1 Creating Payload

    Field Description
    Rule Name The name of the rule. This must be unique for each application.
    Endpoint Name The name of the endpoint API or adapter. You can't update this field.
    External Event Emitter Identification

    The client ID your authorization server assigns to your application.

    Required for OAuth authentication type. Applicable only for external application.

    API ID

    The unique identifier of the API.

    You can add new APIs but you can't delete existing APIs.

    API Name The name of the associated APIs.
    API Version The API version number.
    API Resources

    The resources for which you want to publish events; for example, individual, party, or organization.

    You must add at least one criteria and one rank for a resource.

    Criteria

    The criteria is a set of conditions used for filtering the events you want to publish to listeners. For more information, see the Gatekeeper Criteria topic in this chapter.

    You can use * to indicate that there is no criteria for this resource.

    Criteria

    The order in which you want to apply the criteria. This field is optional. The minimum value is 0. The rank must be different for the same combination of criteria and resource.

    Listener Registration Refs

    The list event listener IDs.

    You can update this only for external applications.

    Destination Selection

    The details of the Open API and the resources, criteria, and rank you want to use with this API. Applicable only for non-TMF APIs. For more information, see the Review Gatekeeper Rules topic in this guide.

    Note: You can use the non-TMF APIs only to route requests.

  2. Call the gatekeeping Rules API by running the following curl command or by using a REST API client:
    curl -H Authorization: Bearer <accessToken> https://<hostName>/admin/<workspace>/gatekeepingRules/{id} -
    X PATCH -H "Content-Type: application/json" -d @gkr-data.json
    
    

    Where:

    • <accessToken> is the OAuth access token for your account.
    • <hostName> is the URL for your API Gateway.
    • <workspace> is the path parameter for the production or test workspace, which is 02 for the test workspace and 01 for the production workspace. If you are calling the API using FA API Gateway, you can skip this parameter.

The API returns the response with an accepted status if the rule is updated.

Here's the sample gatekeeper rule to publish events belonging to individual and organization resources to listeners using a TMF API. The application publishes the events only if the parameters specified in the criteria are present in the event payload:
{
"endpoint-name": "tmf632",
"rule-name": "Generated gatekeeping rule for endpoint tmf632", "gatekeeping-apis": [
{
"api-id": "tmf-632",
"api-name": "Party",
"api-version": "v4", "api-resources": [
{
"resource-name": "Individual", "gatekeeping-criteria": {
"criteria": "(ID pr or /event/individual/familyName pr or /event/individual/id pr or /event/organization/ tradingName pr or /event/organization/id pr)",
"rank": 1
}
},
{
"resource-name": "Organization", "gatekeeping-criteria": { "criteria": "*",
"rank": 1
}
}
]
}
]
}

Gatekeeper Criteria

You specify criteria in the gatekeeper rules to filter the events for publishing. Your criteria can include:
  • Event type: The events you want to publish to the event listeners, for example, CustomerCreateEvent.
  • Attribute: The JSON path to the parameters in the request payload and HTTP header of the request or reserved keywords used as identifiers. The application uses the value of this attribute for comparing the conditions. You can use only the parameters and keywords listed in the Operators, Parameters, and Keywords topic to define the criteria.
  • Operator: The operator for comparing the conditions. You can use only the operators listed in the Operators, Parameters, and Keywords topic to define the criteria.
  • Value: The actual value to be compared. This condition isn't applicable if the operator is pr.
A valid criteria must contain at least one condition. If you have multiple conditions, use these logical operators:
  • and: Indicates that both the conditions are applicable.
  • or: Indicates only one of the conditions is applicable.
  • not: Indicates that the condition isn't applicable.

You can also use parentheses () to indicate the condition that takes precedence over other conditions.

Your criteria can be a combination of the following:
  • Event types and conditions: Use this to publish specified events when the specified conditions are met. For example, to publish customer creation and deletion-specific events if the customer ID is greater than 10000, set this criteria:
    ((/eventType eq "CustomerCreateEvent" or /eventType eq "CustomerDeleteEvent") and "/event/customer/id" gt 10000)
  • Only conditions: Use this to publish all the generated events when the specified conditions are met. For example, to publish all the relevant events if the customer ID is greater than 10000, set this criteria:
    ""/event/customer/id" gt 10000"
  • Only event types: Use this to publish only a subset of events. For example, to publish only customer creation and deletion-specific events, set this criteria:
    "(/eventType eq "CustomerCreateEvent" or /eventType eq "CustomerDeleteEvent")"
    
    

Operators, Parameters, Reserved Keywords

Here are the operators that you can use in your criteria.

Table 8-2 Operators

Operator Description Applicable to
eq Equal to All conditions
ne Not equal to All conditions
co Contains Strings only
sw Start with Strings only
ew End with Strings only
pr Present(represents actual value) All conditions
gt Greater than All conditions
ge Greater than or equal to All conditions
lt Less than All conditions
le Less than or equal to All conditions
Here are the request payload parameters that you can use in your criteria.

Table 8-3 Request Payload Parameters

Parameters Description
id The unique identifier of the event. For example, CDRM_1.
href The reference to the event. For example,"/cx/industry/party/v4/individual/CDRM_123"
familyName The family name of the event. For example, "abc".
fullName The full name of the event. For example, "New Party".
givenName The given name of the event. For example, "New'
status The status of the event. For example, "active".
type The type of the event. For example, "individual".
Here are the reserved keywords that you can use in your criteria.

Table 8-4 Reserved Keywords

Keywords Description
ID

The URL path parameter IDs used in the HTTP Header.

For example, to use only URL path parameter IDs that start with "NEW-" in your criteria, specify the condition as ID sw "NEW- ".

OP

The HTTP method used for an operation.

For example, to use all the GET operations irrespective of the ID in your criteria, specify the condition as OP eq "GET" and not (ID pr).

Note: With notification and delivery APIs, you can use only the POST operation method.

MS
The endpoint types, such as:
  • RMS: for API-specific endpoints
  • NMS: for event-specific endpoints
For example, to use notification APIs and specific values of an incoming event type and an account type in your criteria, specify the condition as:
MS eq "NMS" and /eventType eq "financialAccountCreateEvent" and /payload/financialAccount/accountType eq "business"