Resource Templates With Scope

The scope of resource templates can be defined at enterprise level, environment level, and application level.

The following levels of scope are available:

  • Global or enterprise (default) - available to all environments and applications in the enterprise.
  • Environment - available only to applications in a specific environment.
  • Application - available only to a specific application running on a node or multiple nodes.
The scope of a resource template is specified at the time of creating it. Later it is possible to change the scope. The following are conditions when changing scope:
  • You can specify multiple target elements for a resource template while changing the scope. When multiple target scopes are specified, a resource template in each target scope is created. For example, the resource template with global scope can be scoped to multiple environments or applications.
  • If a resource template has a resource instance linked to it, then changing the scope makes a copy than move the resource template itself. For example, if JDBC_RT has its scope as global and a JDBC_RI linked to it, changing the scope of JDBC_RT will make a copy of it for the environment or application than move it to the new scope and remove it from enterprise.

The image below provides an example of how resource templates are scoped at application, environment, and global levels.



Life Cycle of Application Scope Resource Template

When you scope a resource template to an application, the application owns the resource template and the life cycle of the associated resource instances. When you deploy an application:
  • Resource instances using the resource templates with scope to the application are installed.
  • Resource instances are created in the appropriate nodes as needed.
  • A validation process verifies the application property that needs a resource instance matches the resource template name in the application scope. If the match is found the resource instance is automatically created and installed when the application is deployed.

When you undeploy the application all the resource instances using the resource templates with scope defined to the application are uninstalled.

When an application is deleted, all resource templates with scope to the application and the associated resource instances are deleted. This allows creation of an application once and deployment multiple times without conflict.

Uniqueness

  • Resource templates names are unique in a specified scope. Two resource templates with the same name cannot exist in the same scope irrespective of the resource template type.
  • When a scope is deleted, all resource templates contained in the scope are deleted.
    • When an application is deleted, all resource templates scoped for the application are deleted.
    • Before deleting the resource templates, all resource instances created from the resource templates are un-installed (only relevant for force) and deleted.
  • Two applications whose property containing same resource instance name and containing the corresponding resource template configuration cannot coexist on the same node. However, they can both have properties referring to the same JNDI name as long as only one of them provides the application level resource template. For example, consider:
    • Two applications containing a resource template configuration each with same name.
    • When the application is created, the corresponding resource template is created with in its application scope.
    • When deploying the application, this requires two resource instances to be installed with same name, but it cannot because resource instances with same name cannot coexist on the same node.

Resource Dependency and Auto Creation of Resource Instances

  • Resource templates can depend on other resources defined in its scope or its parents scope. It cannot depend on its child scope for the purpose of auto creation. However, if dependencies are explicitly created, a resource instance can depend on a resource at a child scope. For example, consider that an HTTP_Client resource template exists in the System Environment which depends on a SSL_Client_Provider in the Enterprise. When HTTP resource instance is created and installed on a node:
    1. It looks for the dependency resource instance (SSL_Client_Provider) on the node
    2. If no resource instance exists, Administrator checks whether an SSL_Client_Provider resource template with the same name exist in the System Environment scope. If the resource template is available at the environment scope, Administrator creates a resource instance using the resource template.
    3. If the resource template does not exist in the environment scope , Administrator checks in the Enterprise and creates a resource instance if the resource template is available.

However, if the SSL_Client_Provider resource instance with the same name already exists in the specified node, the HTTP_Client will depend on it irrespective of its scope.

Permissions

Users need permission to create resource templates and change the scope. For example, a user with permission to an environment can create a resource template to be shared across applications in the environment and not globally at enterprise level.

  • Resource templates with global or environment scope have view, edit, and owner permissions that are set individually for each resource templates.

  • For global or environment scope, users with Create Resource Template permission can create resource templates at that scope level.

  • Resource templates with application scope do not have individual permissions. Users who are granted Manage Resource Template permission for the application can create, edit, view, and delete resource templates with application scope.

Other Conditions

  • Resource Templates from one scope are not visible to other scope of the same level. Resource Templates created in SystemEnvironment are not visible to DevEnvironment and thus are not used for auto creation of resource instances nor do they show up in pickers.
  • Resource templates cannot be deleted if a resource instances exists for it.
  • Resource instances cannot be uninstalled when other resource instances depend on it.
  • Resource instances with the same name cannot coexist in the same node.
  • When an application is undeployed, all resource instances using resource templates scoped to that application are uninstalled.
  • When an application is deployed, all Resource Templates scoped to that application are:
    1. Checked against the application's properties to see where they are needed.
    2. If specific nodes are identified this way, then Resource Instances with the same name are created and installed on each of those nodes.
    3. If no properties in the application reference the resource templates, then resource instances are automatically created and installed on every node to which the application is mapped.

If a Resource Instance with the required JNDI name already exists on a node where the above rules would cause auto-creation to happen, then deployment validation fails. If redeployment results in the application being removed from a node, all Resource Instances on that node using Resource Templates scoped to the application are uninstalled and deleted.