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
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
- 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.
- 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.jsonWhere:
<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.
{
"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
- 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.
- 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.
- 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
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 |
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". |
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 |
| 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 Note: With notification and delivery APIs, you can use only the POST operation method. |
| MS |
The endpoint types, such as:
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:
|