1. Managing Oracle Mobile Hub
  2. Configuring Oracle Mobile Hub
  3. Policies

2 Policies

Policies define properties for artifacts on a global or artifact-specific level. You can use policies to adjust how artifacts behave even after they are published.

Even though an artifact can’t be changed after it’s published, its behavior can still be affected. You have the flexibility to adjust policy values to better fit the required behavior of artifacts. For example, you might be testing that a connector’s endpoints are valid. The timeout values don’t matter much during the experimental phase, but when you publish the connector, realistic timeout settings are required. You can adjust the value of the Network_HttpRequestTimeout policy accordingly.

Only Mobile Hub administrators can modify policies. You can modify policies when you deploy an artifact (client, backend, custom API, API implementation, connector, or collection) or by editing the policies.properties file directly from the Administration view. For information on how to change policy settings, see Define Policies.

In most cases, you should leave the policy’s default settings. Make sure you understand the scope of a policy before you change it. When you change a policy with global scope, the value is applied to all relevant artifacts. For details on policy scope, see Policy Scope.

For a list of policies including descriptions, scopes, and default values, see Oracle Mobile Hub Policies.

Define Policies

Define and modify policies by exporting the current policies.properties file, editing the property values, and importing the modified file.
  1. Click open the side menu icon and select Settings from the side menu.
  2. Click Policies and then click Export.
  3. Make a backup copy of the policies.properties file before you update it. If you find you've made unintended changes, you can restore policies to their previous state by importing the backup copy.
  4. Open the exported policies.properties file in a text editor, edit the policies as needed, and save the file.
  5. Go back to the Policies page, click Import, and select the modified policies.properties file.
Here’s an example policies.properties file:
Description of envpolicies_file.png follows
Description of the illustration envpolicies_file.png

Mobile Hub Policy Names

Policy names use the format backendName.apiName.policyName (mbeArtifactIdentity.invocableArtifactIdentity.policyPropertyName):

  • backendName binds the policy value to a specific backend.

  • apiName binds the policy to an API, API implementation, or connector API.

    Note:

    When you define a policy that affects an API, you must use a fully-qualified name, consisting of the API category and the API name (with or without the version). The API category can be: custom, connector, platform, or system. For example: myBackend.custom/myAPI(1.0).propertyName. Policy names for API implementations don’t include category types. For example, *.myAPIImpl(1.0).

  • policyName is the name of the policy (initial-capped and preceded by a category). For a full list of policies, see Oracle Mobile Hub Policies.

To set the scope of the policy you are defining, set the backendName, apiName and policyName in the following ways:

  • A wildcard denoted by an asterisk (*), which binds the policy to all artifacts of the particular type.

  • The artifact name alone, which binds the policy to all artifacts of the particular type with the specified name. For example, myBackend.

  • The artifact name and version, which binds the policy to the artifact of the particular type with the specified name and version, for example, myBackend(1.0.0).

Policy Scope

Policy scope defines which artifacts use the policy’s settings. Policies can be set globally, by artifact type, or for a specific artifact. Some policies don’t support all three scopes. For example, the Connector_Endpoint policy stores the endpoint URL of a specific connector, so it can only be set at the artifact level. The Network_HttpRequestTimeout policy affects APIs and connectors, so it can be set globally.

The combination of values in the name defines the scope for the policy.

  • Global scope: Set both backendName and the apiName as wildcards so that the policy is applied globally.

    For example: *.*.Logging_Level=800

  • Backend scope: Set backendName to a specific backend and set the apiName as a wildcard so that the policy is applied to all APIs and connectors called in the context of the given backend. You make this more specific by including the version of the backend.

    For example: MyBackend(1.3).*.Logging_Level=800

  • API scope: Set backendName to a wildcard and set the apiName to a specific API so that the policy is applied to that particular API when called in the context of any backend. You make this more specific by including the version of the API.

    For example: *.custom/MyApi(2.0).Logging_Level=800

  • API Implementation scope: Set backendName to a wildcard and set the apiName to a specific API implementation so that the policy is applied to that particular implementation when called in the context of any backend. You make this more specific by including the version of the API implementation.

    For example: *.MyApiImpl(1.0).Logging_Level=800

  • Connector scope: Set backendName to a wildcard and set the apiName to a specific connector so that the policy is applied to that particular connector when called in the context of any backend. You make this more specific by including the version of the connector.

    For example: *.connector/MyConnector(2.2).Logging_Level=800

  • Fully-qualified API scope: Set the backendName to a specific backend and set the apiName to a specific API so that the policy is scoped at the fully-qualified API level whenever the API is called within the scope of the given backend. You make this more specific by including the version of the backend and the API.

    For example: MyBackend(1.3).custom/MyApi(2.0).Logging_Level=800

  • Fully-qualified API Implementation scope: Set the backendName to a specific backend and set the apiName to a specific API Implementation so that the policy is scoped at the fully-qualified API implementation level whenever the implementation is called within the scope of the given backend. You make this more specific by including the version of the backend and the API implementation.

    For example: MyBackend(1.3).MyApiImpl(1.0).Logging_Level=800

  • Fully-qualified Connector scope: Set the backendName to a specific backend and set the apiName to a specific connector so that the policy is scoped at the fully-qualified connector level whenever the connector is called within the scope of the given backend. You make this more specific by including the version of the backend and the connector.

    For example: MyBackend(1.3).connector/MyConnector(2.2).Logging_Level=800

Remove Policies

You can reduce clutter in the policies.properties file by removing policies defined for obsolete artifacts.

To remove policies:
  1. Click open the side menu icon and select Settings from the side menu.
  2. Click Policies and then click Export.
  3. Make a copy of the exported policies.properties file as a backup.
  4. Open the file in a text editor and delete the policies you want to remove. Save the file.
  5. Back on the Settings page, select Delete all policies before import.
  6. Import the modified policies.properties file.
All the previous policies are deleted, leaving only the policies you imported from the modified file. If you find you've accidentally deleted the wrong policies, you can restore policies to their previous state by importing the backup copy of the file.