Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

This document covers the following topics:

• Call Web Service

• Change Activation State

• Change Deployment Status

• Classify

• Consumer WSDL Generator

• Default Move Handler

• Delete RuntimeEvents and RuntimeMetrics

• Enforce Unique Name

• Initiate Approval

• Initiate Group-Dependent Approval

• Mark Pending On RuntimePolicy Change

• Notify ARIS Service

• On Consumer Registration Request Send Email to Owner

• Processing Steps Status

• Promote Asset

• Register Consumer

• Send Email Notification

• Set Attribute Value

• Set Consumer Permission

• Set Instance and Profile Permissions

• Set Permissions

• Set Profile Permissions

• Set State

• Set View Permission For Service And Service Related Object To Everyone Group

• Send Email Notification to Watchers

• UnClassify

• Validate Attribute Value

• Validate Classification

• Validate Description

• Validate Lifecycle Model Activation

• Validate Name

• Validate Namespace

• Validate Policy Activation

• Validate Policy Deactivation

• Validate Service Binding

• Validate State

• Validate WSDL Size

• webMethods REST Publish

Call Web Service

Submits a given SOAP message to a specified Web service. You can use this action to notify external systems, via a SOAP message, of changes that occur in the registry.

If the Web service returns a response, the response message is recorded to the policy log.

If the Web service produces a SOAP fault or the service cannot be successfully performed for other reasons (e.g., a network failure occurs), the policy action fails, and thus the policy itself fails. If the policy had been executed on a "pre" operation event (e.g., PreCreate, PreDelete), the requested operation is not executed.

Event Scope

PreCreate
PostCreate
PreUpdate
PostUpdate
PreDelete
PostDelete
PreStateChange
PostStateChange
OnTrigger

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
	  <env:Body>
		    <m:keylogger xmlns:m=" http://mycompany.example.org/key ">
		      	<serviceName>${entity.name}</serviceName>
		      	<assetType>${entity.type}</assetType>
		      	<key>${entity.attribute.Key}</key>
		    </m:keylogger>
	  </env:Body>
</env:Envelope>

Change Activation State

Activates or deactivates a lifecycle model or a policy.

Event Scope

PostStateChange
OnTrigger

Object Scope

Lifecycle Model
Policy

Input Parameters

Change Deployment Status

Enables or disables the deployment status of a virtual service. You use this action to specify whether the given virtual service is eligible or ineligible for deployment.

• When you enable the deployment status for a virtual service, you enable the controls on the Deployment profile. These controls enable authorized users to deploy, undeploy or redeploy the virtual service.

  Additionally, enabling the deployment status of a virtual service makes the virtual service eligible for automatic re-deployment when changes occur to its run-time policies.

• When you disable the deployment status for a virtual service, you disable the controls on the virtual service's Deployment profile (thus, preventing users from deploying, undeploying or redeploy the virtual service).

  When the deployment status for a virtual service is in the disabled state, the virtual service is not eligible for automatic re-deployment when changes occur to its run-time policies.

  Note:
  Disabling the deployment status of a virtual service does not undeploy the virtual service if it is already deployed. If the virtual service is currently deployed on a Mediator, it remains deployed there. However, administrators will not be able to undeploy or redeploy the virtual service from CentraSite Control until its deployment status is enabled.

To enable the deployment status of a virtual service, the following conditions must be satisfied:

• There must be at least one target defined in the registry.

• The Entry Protocol and Routing steps must be configured.

Typically, you use this action in combination with the Processing Steps Status action, which enables and disables the Processing Steps profile for a virtual service. For example, when you enable the Deployment profile, you generally disable the Processing Steps profile and vice versa.

Event Scope

PostStateChange

Object Scope

Service
Virtual Service
Virtual REST Service
Virtual XML Service

Input Parameters

Classify

Classifies the target object (i.e., the object on which the policy was triggered) by one or more taxonomy categories. You can assign the taxonomy categories to a classification attribute of the target object, or you can assign the taxonomy categories as normal classifications of the target object.

The classifications you assign using this action will appear on the asset's Classification tab. The classifications you assign will also appear for the selected classification attribute.

You can choose whether the classifications you specify with this action will be added to the object's existing classifications or whether they will replace the object's existing classifications. This choice is only available for multi-value classification attributes, i.e. classification attributes that can reference more than one taxonomy category. If a classification attribute is a single-value classification attribute, its existing value will be replaced by the new one.

Event Scope

PostCreate
PostStateChange
OnTrigger
OnConsumerRegistration

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Consumer WSDL Generator

Enables the Consumer WSDL option on the Specification profile of SOAP-based virtual services. For information about the Consumer WSDL option, see the topic The Specification Profile in the section Viewing or Editing the Profiles of Virtualized Services in the document Working with Virtualized Services.

Event Scope

PreCreate
PreUpdate
OnTrigger

Object Scope

Virtual Service

Input Parameters

None.

Default Move Handler

Performs standard actions when an object's owner or organization changes.

This action is included in the Default Move Handler policy that is installed with CentraSite. This is the default policy that executes when an object is moved to a new owner or organization. See the section Changing the Ownership of an Asset in the document Using the Asset Catalog for related information.

Event Scope

OnMove

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Delete RuntimeEvents and RuntimeMetrics

Deletes the events and metrics that have been logged for a service.

This action is included in the Delete RuntimeEvents and RuntimeMetrics of Service policy that is installed with CentraSite. This policy executes when a service is deleted. The policy ensures that the metrics and events associated with a service are removed from the run-time logs when a service is deleted.

Event Scope

PreDelete

Object Scope

Service
Virtual Service
REST Service
Virtual REST Service
XML Service
Virtual XML Service
CEP Event Type

Input Parameters

Enforce Unique Name

Ensures that the names of objects that are created in CentraSite are unique.

This action is included in the Enforce Unique Name policy that is installed with CentraSite. For information about this policy, see the section Using CentraSite with ARIS in the document Suite Usage Aspects.

Event Scope

PreCreate
PreUpdate
PreStateChange
OnTrigger

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Initiate Approval

Initiates an approval workflow.

When this action is executed, CentraSite initiates the approval process. CentraSite will not process any subsequent actions in the policy or execute the requested operation until the approvals specified by the Initiate Approval action are received.

For more information about creating approval policies, see the section Using Approval Policies in the document Working with Design/Change-Time Policies.

Caution:
When you use this action on the PreStateChange event, only certain kinds of actions can be executed after this action in an approval policy. Some actions, if they occur after this action, will cause the policy to fail. For information about what kind of actions can follow this approval action, see the topic Adding an Approval Policy to CentraSite in the section Using Approval Policies in the document Working with Design/Change-Time Policies.

Note:
To use the email options provided by this action, CentraSite must have a connection to an SMTP email server. For instructions on how to configure CentraSite's connection to an email server, see the section Configuring the Email Server in the document Basic Operations.

If You Migrate this Action from a Pre-8.2 Release

If you have a policy that contains this action and the policy was created prior to version 8.2, that policy will continue to exhibit the old email-notification behavior (i.e., it will continue to send the earlier version's standard email message to approvers). If you want to use the email-notification enhancements that were introduced in version 8.2, simply edit the policy and enable the email parameters in the Initiate Approval action.

Event Scope

PreStateChange
OnConsumerRegistration

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

AnyOne

EveryOne

Initiate Group-Dependent Approval

Initiates an approval workflow based on the group to which the requestor belongs. If the requestor does not belong to any of the groups specified in the Triggering Groups array, approval is waived and the action is considered to be completed successfully. For more information about using group-based approvals, see the topic Using the Initiate Group-Dependent Approval Action in the section Using Approval Policies in the document Working with Design/Change-Time Policies.

Caution:
When you use this action on the PreStateChange event, only certain kinds of actions can be executed after this action in an approval policy. Some actions, if they occur after this action, will cause the policy to fail. For information about what kind of actions can follow this approval action, see the topic Including Multiple Actions in an Approval Policy in the section Using Approval Policies in the document Working with Design/Change-Time Policies.

Note:
To use the email options provided by this action, CentraSite must have a connection to an SMTP email server. For instructions on how to configure CentraSite's connection to an email server, see the section Configuring the Email Server in the document Basic Operations.

If You Migrate this Action from a Pre-8.2 Release

If you have a policy that contains this action and the policy was created prior to version 8.2, that policy will continue to exhibit the old email-notification behavior (i.e., it will continue to send the earlier version's standard email message to approvers). If you want to use the email-notification enhancements that were introduced in version 8.2, simply edit the policy and enable the email parameters in the Initiate Group-Dependent Approval action.

Event Scope

PreStateChange
OnConsumerRegistration

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Mark Pending On RuntimePolicy Change

Marks the deployed virtual services or consumer applications that are within the scope of run-time policy as pending for redeployment on activation or deactivation of the policy. After the policy is activated, the virtual services and consumer applications are automatically redeployed.

This action is included in the Mark Pending-For-Redeployment On RuntimePolicy Change policy that is installed with CentraSite. This policy executes when a run-time policy switches to the Productive state (which activates the policy) or Suspended state (which deactivates the policy).

If you customize the lifecycle model that CentraSite provides for policies and you add additional states to the model, you must execute this action during any transition that changes the activation state of a policy.

Event Scope

PreStateChange

Object Scope

Policy

Input Parameters

None.

Notify ARIS Service

Notifies the ARIS APG Service endpoint with the SOAP request message provided in this action. The APG Service endpoint is picked up from the associated ARIS Application Server.

You can use this action in the following policies:

• Notify ARIS on Process Changes

• Notify ARIS on Service Changes

• Notify ARIS on Service Completion

• Notify ARIS on Service Deletion

For information about these policies, see the section Using CentraSite with ARIS in the document Suite Usage Aspects.

Event Scope

PostUpdate
PostDelete
PostStateChange
OnTrigger

Object Scope

Process
Service

Input Parameters

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.idsscheer.com/age/webMethods/">
   <soapenv:Header/>
   <soapenv:Body>
      <web:UpdateServiceRequest>
         <dbname>${context.ARIS_DB_CONTEXT}</dbname> 
         <language>${user.locale}</language>
         <serviceDetail>
            <guid>${entity.key}</guid>
            <name>${entity.name}</name>
            <url>${entity.URL}</url>
            <lifeCycleState>${entity.state}</lifeCycleState>
            <owner>${entity.owner}</owner>
            <description>${entity.description}</description>
            <organization>${entity.organization}</organization>
            <version>${entity.version}</version>
            ${entity.attribute.Operations}
         </serviceDetail>
      </web:UpdateServiceRequest>
   </soapenv:Body>
</soapenv:Envelope>

On Consumer Registration Request Send Email to Owner

This action template allows an email to be sent to the owner of an object if there is a consumer registration request for the object.

Event Scope

PreCreate

Object Scope

Consumer Registration Request

Input Parameters

Processing Steps Status

Enables or disables the Processing Steps profile for a virtual service.

• When you enable the processing steps status for a virtual service, you enable the controls on the Processing Steps profile for that virtual service. These controls enable authorized users to modify the processing steps for the virtual service.

• When you disable the processing steps status for a virtual service, you disable the controls on the Processing Steps profile. While this profile is disabled, users cannot make changes to the virtual service's processing steps.

Typically, you use this action in combination with the Change Deployment Status action, which enables and disables the Deployment profile for a virtual service. For example, when you enable the Processing Steps profile for a virtual service, you generally disable the Deployment profile and vice versa.

Event Scope

PostStateChange

Object Scope

Service
Virtual Service
Virtual REST Service
Virtual XML Service

Input Parameters

Promote Asset

This policy action allows you to promote an asset instance to a different CentraSite stage. The action can be executed on a lifecycle pre-state change, post-state change or on an OnTrigger event. The configuration options cover the following options:

• Specify a stage to promote to
  This can be either the name of a lifecycle stage or the URL of the target registry.

• Specify optional user credentials for the target stage
  The credentials specify a user name and password of a user defined on the target registry. This user should have the required permissions to create the asset on the target registry.

• Include referenced objects in the promotion set
  Assets that are referenced by the asset being promoted can be included in the promotion process.

• Keep the asset owner unchanged
  You can specify that the owner of the asset in the source registry will also be the owner in the target registry. If this user does not exist in the target registry, the owner will be the user specified in the optional user credentials described above.

  This user should be able to create assets in the target organization, which can be any of the following, depending on the input parameters you specify:

  • The organization mentioned in the Target Organization parameter.

  • The organization to which the user in the target registry belongs.

  • The organization to which the triggering user or the user in the Username parameter belongs.

• Replace existing registry objects in the target stage
  If an asset already exists on the target stage, it may be replaced by the asset being promoted.

• Specify a target organization name
  When the asset is promoted, it will belong to the organization specified.

• Keep the lifecycle state
  You can specify a lifecycle state for the promoted asset on the target registry. If you do not specify a state, the promoted asset will be placed in the initial state of the lifecycle model on the target registry.

Event Scope

PreStateChange
PostStateChange
OnTrigger

Object Scope

Asset

Input Parameters

The following table lists the input parameters for the policy action.

As noted in the table, some of the promotion operations are only possible if the target stage contains users, organizations and lifecycle models that are compatible with those defined on the source stage. The possible combinations are listed in the following tables.

Note:
During the promotion process, CentraSite copies the metadata of an asset from the source instance to the target instance. However, if the action is to be executed during a prestatechange event, the changes to the metadata in the source instance are not reflected in the target instance. You will need to explicitly update the asset if you want that change reflected in the target instance, too.

Important:
Before you activate a policy that includes the Promote Asset action, ensure that the target's specified target stage URL or target stage is active and the user credentials of target registry are valid. To check this, click the Check Connection button. If the connection is not active and valid, activate the target specified in Target Stage or Target Stage URL and modify the user credentials as required.

Target Organization and Target Owner

When the asset is promoted to the target registry, it will belong to a specific organization and will be owned by a specific user. The organization and owner on the target registry are not necessarily the same organization and owner as on the source registry.

The owner on the target registry can be one of the following:

• the same owner as on the source registry (called "User A" in the following description)

• the user specified in the Username parameter (called "User B" in the following description)

• the triggering user, i.e. the user who activates the asset promotion (called "User C" in the following description)

The organization on the target registry can be one of the following:

• the organization specified in the Target Organization parameter (called "Organization P" in the following description)

• the organization of the user supplied in the Username parameter (called "Organization Q" in the following description)

• the organization of the triggering user (called "Organization R" in the following description)

Target Owner:

Target Organization

CentraSite attempts to create the asset on the target registry using the resulting combination of target owner and target organization. If the given user does not have permission to create assets in the given organization, the promotion will fail.

Keep Lifecycle State

Register Consumer

Registers users, groups and/or consumer applications (as specified by the requestor) as consumers of an asset. This action creates a "consumed-by" relationship between the asset and the specified consumers. Once established, this relationship is visible in the asset's Consumers profile and also on the asset's Impact Analysis page.

The following actions are typically used in conjunction with the Register Consumer action.

• The approval actions (Initiate Approval or Initiate Group-Dependent Approval) are generally used to obtain necessary approvals prior to executing the Register Consumer action.

• The Set Consumer Permission action is typically executed after the Register Consumer action to give the specified consumers access to the requested asset.

Event Scope

OnConsumerRegistration

Object Scope

Asset (any type)

Input Parameters

None.

Send Email Notification

Sends an email message to specified users and/or groups.

Note:
To use this action, CentraSite must have a connection to an SMTP email server. For instructions on how to configure CentraSite's connection to an email server, see the section Configuring the Email Server in the document Basic Operations.

Note:
During an iteration of the policy, if the connection to a SMTP email server fails, this policy action returns a failure code. CentraSite writes the failure message to the policy log; however performs the next action in the policy (if one exists).

Event Scope

PreCreate
PostCreate
PreUpdate
PostUpdate
PreDelete
PostDelete
PreStateChange
PostStateChange
OnConsumerRegistration
OnTrigger

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Substitution Tokens

The following list describes substitution tokens that you can use to incorporate data from the run-time instance of a policy into the email. For example, you can use tokens to return information about the object on which the policy is acting, identify the user who triggered the policy, and/or indicate what type of event caused the policy to fire.

Be aware that some tokens are only meaningful for certain types of objects. User objects, for example, do not have a Description attribute, so the ${entity.description} token has no meaning for a User object. If you use a substitution token that is not supported by the policy's target object, CentraSite simply replaces the substitution token with a space at enforcement time.

If the target object includes the requested attribute, but the attribute itself has no value, CentraSite also replaces the substitution token with a space in the email message. If the requested attribute contains an array of values, CentraSite inserts the values into the email as a comma-separated list.

Example

User ${entity.owner} has added the following asset to the catalog: Name: ${entity.name} Description: ${entity.description}

Set Attribute Value

Assigns a value to a specified attribute in an organization, user or asset.

Event Scope

Post-State Change
OnTrigger
OnConsumerRegistration
Pre-Create
Post-Create

Object Scope

Organization
User
Asset (any type)

Input Parameters

Set Consumer Permission

Assigns permission settings to the users and/or groups who are identified by a consumer-registration request.

The behavior of this action with respect to specific asset profiles depends on the policy's object scope.

• If you use this action in a policy that applies to multiple asset types, you can set only the asset's top-level View/Modify/Full permissions. Consumers do not receive View or Modify permission on the individual profiles associated with the asset. You will have to assign permissions to the asset's individual profiles manually.

• If you use this action in a policy that applies to one (and only one) type of asset, you can set the asset's top-level View/Modify/Full permissions and also the View/Modify permissions on its individual profiles.

The permission settings you specify in this action will either replace or be merged with the asset's existing settings, depending on how you set the Remove Existing Permission parameter.

If you set Remove Existing Permission to true, the permission settings specified in the action completely replace the asset's current settings. That is, the asset's previous instance-level settings are completely cleared and the permissions specified by the action are set.

For example if an asset's initial permission settings are as follows:

USER A    Full
USER B    Full

And you specify the following permissions (with Remove Existing Permission set to true):

USER A    Full
GROUP X   Modify

The resulting permissions on the asset will be:

USER A    Full
GROUP X   Modify

If you set Remove Existing Permission to false, the permission settings specified by this action are added to the asset's current settings. So, for example, if an asset has the following permission settings:

USER A    Full
USER B    View

And you specify the following permissions (with Remove Existing Permission set to false):

USER A    Modify
USER B    Full
GROUP X   Modify

The resulting permissions on the asset will be:

USER A    Full
USER B    Full
GROUP X   Modify

Note:
The instance-level permissions that this action assigns to a user does not affect any role-based permissions that the user might already have. For example, if user ABC has "Manage Assets" permission for an organization, and that user also happens to be a member of a group to which this action assigns instance-level permissions, user ABC's "Manage Assets" permission will override the permission settings that this action assigns to him or her.

Event Scope

OnConsumerRegistration

Object Scope

Asset (any type)

Input Parameters

Set Instance and Profile Permissions

Sets instance-level permissions on an asset. You can use this action to set top-level View/Modify/Full permissions on an entire asset and to set View/Modify permissions on individual profiles within an asset.

Note:
You use this action to set permissions on assets only. To set permissions on policies, you must use the Set Permissions action. If you want to assign asset permissions to consumers during the consumer registration process, use the Set Consumer Permission action.

Be aware that the behavior of this action varies depending on the policy's object scope.

• If you use this action in a policy that applies to multiple asset types, you can only use it to set the asset's top-level View/Modify/Full permissions. Users do not receive View or Modify permission on the individual profiles associated with the asset. You have to assign permissions to the asset's individual profiles manually.

• If you use this action in a policy that applies to one (and only one) type of asset, you can use it to set the asset's top-level View/Modify/Full permissions and also the View/Modify permissions on its individual profiles.

The permission settings you specify in this action will either replace or be merged with the asset's existing settings, depending on how you set the Remove Existing Permission parameter.

If you set Remove Existing Permission to true, the permission settings specified in the action completely replace the asset's current settings. That is, the asset's previous instance-level settings are completely cleared and the permissions specified by the action are set.

For example if an asset's initial permission settings are as follows:

USER A    Full
USER B    Full

And you specify the following permissions (with Remove Existing Permission set to true):

USER A    Full
GROUP X   Modify

The resulting permissions on the asset will be:

USER A    Full
GROUP X   Modify

If you set Remove Existing Permission to false, the permission settings specified by this action are added to the asset's current settings. So, for example, if an asset has the following permission settings:

USER A    Full
USER B    View

And you specify the following permissions (with Remove Existing Permission set to false):

USER A    Modify
USER B    Full
GROUP X   Modify

The resulting permissions on the asset will be:

USER A    Full
USER B    Full
GROUP X   Modify

Note:
The instance-level permissions that this action assigns to a user does not affect any role-based permissions that the user might already have. For example, if user ABC has "Manage Assets" permission for an organization, and that user also happens to be a member of a group to which this action assigns instance-level permissions, user ABC's "Manage Assets" permission will override the permission settings that this action assigns to him or her.

Event Scope

PostCreate
PreStateChange
PostStateChange
OnTrigger

Object Scope

Asset (any type)

Input Parameters

Set Permissions

Grants View, Modify or Full permissions to specified users (or to groups of users) for a policy.

Note:
You use this action to set permissions on policy objects. To set permissions on catalog assets, you must use Set Instance and Profile Permissions.

Be aware that the permission settings you specify in the action will either replace or be merged with the object's existing settings, depending on how you set the Remove Existing Permission parameter.

If you set Remove Existing Permission to true, the permission settings specified in the action will completely replace the object's current settings. That is, the action will clear the object's existing permission settings and replace them with the permissions you specify.

For example if a policy's initial permission settings were as follows:

USER A     Full
USER B     Full
GROUP ABC  Full

And you were to specify the following permissions with Remove Existing Permission set to true:

USER A     Full
GROUP X    Modify

The resulting permissions on the asset would be:

USER A     Full
GROUP X    Modify

If you set Remove Existing Permission to false, the permission settings specified in the action are added to the object's current settings. That is, the action will merge the new permission settings with the object's existing settings. For example, if an asset had the following permission settings:

USER A     Full
USER B     View
GROUP ABC  View

And you were to specify the following permissions with Remove Existing Permission set to false:

USER A     Modify
USER B     Full
GROUP X    Modify

The resulting permissions on the asset will be:

USER A     Full
USER B     Full
GROUP X    Modify
GROUP ABC  View

Note:
The instance-level permissions that this action assigns to a user will not affect any role-based permissions that the user might already have. For example, if user ABC has "Manage Policies" permission for an organization and that user also happens to be a member of a group to which this action assigns instance-level permissions, user ABC's "Manage Policies" permission will override the permission settings that this action assigns to him or her.

Event Scope

PostCreate
PreStateChange
PostStateChange
OnTrigger

Object Scope

This action can be enforced on the following object types.

Policy

Input Parameters

Set Profile Permissions

This action sets an asset's profile permissions for the users/groups specified without setting the asset's instance level permissions.

The users/groups specified in the parameter should have view or modify instance level permission on the asset.

Event Scope

PostCreate
PreStateChange
PostStateChange
OnTrigger

Object Scope

Asset (any type)

Input Parameters

Set State

Initiates a lifecycle state change for a lifecycle model, policy, asset or Process object.

When you use this action, be aware that:

• The state change performed by this action will trigger PreStateChange or PostStateChange policies if such policies exist for the specified state change.

• When CentraSite executes this action at enforcement time, it attempts to change the target object to the state you have specified. If this state is not a valid transition from the object's current state, the action will fail.

• If the target object is already in the specified state at enforcement time, this action does nothing. It does not initiate a state change. It simply exits and returns a successful completion code (i.e., this condition is not considered an error).

Event Scope

PostStateChange
OnTrigger
OnConsumerRegistration

Object Scope

Lifecycle Model
Policy
Asset (any type)
Process object

Input Parameters

Set View Permission For Service And Service Related Object To Everyone Group

Grants the View permission on a given service to the Everyone group. When permission is given to Everyone, all users, including guests, are able to view the service and its related interface, operation and binding objects. This policy action enables UDDIv2 clients to access the service without providing an authtoken.

This action is included in the UDDIv2 Inquiry Policy policy that is installed with CentraSite. This policy executes when a service or virtual service is created. This policy is disabled by default.

Event Scope

PostCreate
OnTrigger

Object Scope

Assets

Input Parameters

None.

Send Email Notification to Watchers

Sends an email notification to the watchers for an asset who are specific users asked to be notified for any modifications on that particular asset.

Note:
This action is applicable to the CentraSite Business UI.

Event Scope

PostUpdate
PostDelete
OnTrigger

Object Scope

Asset (any type)

Input Parameters

UnClassify

Removes specified taxonomy categories from an object.

You can use this action to unclassify an object generally or specifically. If you want to unclassify an object by removing from it all categories for an entire taxonomy, use the Taxonomies parameter to specify the taxonomy name. If you want to unclassify an object by removing just one particular category from its classification attributes, you use the Categories parameter to specify a specific category name. Both parameters can be used in the same action.

This action is executed against all classification attributes in the target object.

If the target object is not classified by any of the taxonomies or classifiers specified in the Taxonomies or Categories parameters, the action simply exits and returns a successful completion code. This condition is not considered to be an error.

Event Scope

PostStateChange
OnTrigger
OnConsumerRegistration

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Validate Attribute Value

Validates the value of a specified attribute in an organization, user or asset against a list of allowed values.

Event Scope

PreStateChange
PreDelete
OnTrigger
OnConsumerRegistration

Object Scope

Organization
User
Asset (any type)

Input Parameters

Validate Classification

Checks whether an object is classified by a given taxonomy or taxonomy category. This action examines all classification attributes in the target object.

If you just want to check that the target object has been classified by a given taxonomy, simply specify the taxonomy in the Taxonomies parameter. Leave the Categories parameter empty. The action will succeed if the object is classified by any category in the taxonomy (i.e., the action succeeds if the object includes at least one Classification attribute whose value represents a category that belongs the specified taxonomy).

If you want to check that the target object has been classified by a specific category in a taxonomy, specify the exact category in the Categories parameter. Leave the Taxonomies parameter empty. The action will succeed only if the object has been classified by the exact category you specify (i.e., the object includes at least one Classification attribute whose value is set to that specific category).

If you specify multiple taxonomies and categories in the Taxonomies and Categories parameters, be aware that action will succeeds if the target object is classified according to any taxonomy specified in the Taxonomies parameter or any category specified in the Categories parameter. If you need to verify that an object has been classified by several different taxonomies or categories, you must test for each required taxonomy or category using a separate Validate Classification action.

Event Scope

PreStateChange
PreDelete
OnTrigger
OnConsumerRegistration

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Validate Description

Validates the description of an object against a given pattern string.

Event Scope

PreCreate
PreStateChange
OnTrigger

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Validate Lifecycle Model Activation

Verifies that a lifecycle model is ready to be activated by checking that the following conditions exist for the lifecycle model:

• That the lifecycle model is associated with at least one object type.

• That the object types associated with the lifecycle model are not already assigned to an active lifecycle model in your organization. (This check ensures that, within your organization, each object type is associated with no more than one lifecycle model.)

The action will not succeed unless both conditions are satisfied.

You should include this action in any policy that is triggered by a lifecycle state change that subsequently activates the lifecycle model. Executing this action before the state change occurs ensures that the state change (and subsequent activation) will not occur unless the lifecycle model is capable of being activated.

This action is executed by the default Validate Lifecycle Activation policy that is installed with CentraSite. The Validate Lifecycle Activation policy executes on the PreStateChange event that occurs when a lifecycle model switches to the Productive lifecycle state. The Validate Lifecycle Activation action in this policy ensures that a lifecycle model is not switched to the Productive state (and consequently, activated) unless the model has been properly associated with one or more object types.

Event Scope

PreStateChange

Object Scope

Lifecycle Model

Input Parameters

None.

Validate Name

Validates the name of an object against a given pattern string.

Event Scope

PreCreate
PreStateChange
OnTrigger

Object Scope

This action can be enforced on any object type that the policy engine supports.

Input Parameters

Validate Namespace

Checks that the targetnamespace attribute in a Web Service or XML Schema matches one of the valid namespaces in a given list.

Event Scope

PreCreate
PreStateChange
OnTrigger

Object Scope

XML Schema
CEP Event Type
Service
Virtual Service
REST Service
Virtual REST Service
XML Service
Virtual XML Service

Input Parameters

Validate Policy Activation

Verifies that a policy is ready to be activated by checking that the following conditions exist for the policy:

• That all of the required parameters in the policy's action list have been set.

• That all of the actions in the action list are supported by the policy's specified scope. That is, that the policy does not contain any action whose scope includes an object type or event type that is outside the scope of the policy itself. For additional information about requirements relating to an action's scope within a policy, see the topic Policy Scope and Action Scope in the section Functional Scope in the document Working with Design/Change-Time Policies.

• That a policy that contains one or more WS-I actions contains only WS-I actions.

• That a policy that executes on a PreStateChange or PostStateChange specifies the lifecycle states that will trigger the policy.

• Whether a previous version of the policy is already active, and if so, it verifies that the policy can be switched to a state in which it is retired or superseded.

The action will not succeed unless all conditions are satisfied.

You should include this action in any policy that is triggered by a lifecycle state change that subsequently activates the policy. Executing this action before the state change occurs ensures that state change (and subsequent activation) will not occur unless the policy is capable of being activated.

This action is executed by the default Validate Policy Activation policy that is installed with CentraSite. The Validate Policy Activation policy executes on the PreStateChange event that occurs when a policy switches to the Productive lifecycle state. The Validate Policy Activation action in this policy ensures that a policy is not switched to the Productive state (and consequently activated) unless the policy's action parameters have been set.

Event Scope

PreStateChange

Object Scope

Policy

Input Parameters

None.

Validate Policy Deactivation

Verifies that a policy is not currently "in-progress" (i.e., undergoing execution) and can therefore be successfully deactivated. If the policy is in-progress when this action is executed, this action will fail.

You should include this action in any policy that is triggered by a lifecycle state change that subsequently deactivates the policy. Executing this action before the state change occurs helps ensure that the stage change (and subsequent policy deactivation) will not take place if the target policy is in-progress.

Note:
A policy that initiates an approval workflow is considered to be "in-progress" until the required approvals are obtained for the workflow. Therefore, if the Validate Policy Deactivation action is triggered for a policy that is associated with one or more pending approval workflows, the action will fail.

This action is executed by the default Validate Policy Deactivation policy that is installed with CentraSite. The Validate Policy Deactivation policy executes on the PreStateChange event that occurs when a policy switches to the Revising or Retired state. The Validate Policy Deactivation action in this policy ensures that a policy is not switched to the Revising or Retired state (and consequently, deactivated) while it is undergoing execution.

Event Scope

PreStateChange

Object Scope

Policy

Input Parameters

None.

Validate Service Binding

Checks that a Web Service supports the specified bindings.

Event Scope

PreCreate
PreStateChange
OnTrigger

Object Scope

Service
Virtual Service

Input Parameters

Validate State

Validates the current state of a lifecycle model, policy or asset against a given list of states.

Event Scope

PreDelete
OnTrigger
OnConsumerRegistration

Object Scope

Lifecycle Model
Policy
Asset (any type)

Input Parameters

Validate WSDL Size

Checks the size of the WSDL document associated with a Web Service to ensure it falls within a specified range.

Event Scope

PreCreate
PreStateChange
OnTrigger

Object Scope

Service
Virtual Service

Input Parameters

webMethods REST Publish

Creates a REST service from the published IS service interface object.

The action is included in the webMethods REST Publish policy that is installed with CentraSite. This policy automatically executes when the webMethods Designer publishes an IS Service Interface object.

Important:
This IS Service Interface object should be classified under the concept called "WMAssetType -> Integration Server Asset -> TypeOfIntegrationServiceInterface -> REST Service".

Event Scope

Post-Create
Pre-Update

Object Scope

IS Service Interface

Input Parameters

None.

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT