Understanding Activities
An activity is a temporary context within which you define policies and assign them to devices. You do not need to create an activity to import, create, or delete devices (unless you perform policy discovery as part of the action), or to perform various system management tasks.
The requirements for creating or opening activities differ depending on your Workflow mode:
-
Non-Workflow mode with Ticket Management—An activity is created automatically and transparently whenever you open a ticket. If you do not explicitly open a ticket, you are prompted to create a new ticket or open an existing one whenever you perform an action that requires an activity. You must actively open and manage tickets in this mode.
-
Non-Workflow mode without Ticket Management—An activity is created automatically and transparently for you whenever you define, modify, or assign policies to devices. The same activity is used until you submit your changes to the database, and is automatically closed and reopened as needed. You cannot actively open or manage activities in non-Workflow mode. These types of activities are also called configuration sessions.
-
Workflow mode—If you do not explicitly open an activity, you are prompted to create a new activity or open an existing one whenever you perform an action that requires an activity. You must actively open and manage activities in Workflow mode.
Note |
Workflow mode works in the same manner whether Ticket Management is enabled or not. Enabling Ticket Management in Workflow mode simply enables the Ticket field for use with Activities. Entering a ticket ID is not required, but if one is used, the Ticket field can be configured to link to an external change management system. For more information, see Ticket Management. |
When you create an activity, or one is created for you, you open a virtual copy of the Security Manager policy database. You define and assign policies within this copy. Changes that you made within this copy are only available within the copy. Other users in different activities cannot see these changes. After the activity is submitted and, in Workflow mode, approved, the changes within this copy are committed to the database so that all other users can view the changes. Then, you can create a deployment job to generate the relevant CLI commands and deploy them to the devices.
How you submit your activity changes differs depending on Workflow mode:
-
Non-Workflow mode with Ticket Management (default)—Select
to submit your changes to the policy database. -
Non-Workflow mode without Ticket Management—Select
to submit your changes to the policy database. -
Workflow mode—Select
if you are working with an activity approver, or if you do not have a separate activity approver.
The following topics describe why activities are important and how they operate in Workflow mode:
Benefits of Activities
You use activities to control changes made to policies and policy assignments. Although how activities are implemented depends on the workflow settings you choose, all activities provide the following benefits:
-
Audit trail—Activities track changes that are made in Security Manager. You can use this information to determine what changes were made and who made the changes as described in Viewing Activity/Ticket Status and History. For both Workflow and non-Workflow mode, there is also an audit report that provides visibility into activities and other actions, as described in Working with Audit Reports.
-
Safety mechanism—Activities provide a means for experimenting with changes. Because you are making the changes to a private database view, if you do not want to implement the changes, you can easily discard the activity or configuration session. For more information, see Discarding an Activity/Ticket.
-
Task isolation—The policies that are modified within an activity (or configuration session) are locked from being modified within other activities. This prevents conflicting changes that could make a policy unstable. For more information, see Activities and Locking.
In addition, the changes you make within an activity are visible only within the activity. Other users see only the last approved committed configurations, unless they view your activity before you close it (in Workflow mode).
Activity Approval
When you enable Workflow mode, you can choose to operate with or without an activity approver.
If your organization requires a different person with higher permissions to approve activities, you can enable workflow with an approver. When using Workflow mode with an approver, the activity must be approved by a person with the appropriate permissions so the policies can be committed to the database. This approval process at the policy definition level helps to ensure that no inappropriate configurations reach the network devices.
If you choose to operate without an approver, the person defining the policies has the permissions to approve them.
For information about enabling or disabling activity approval and changing the default activity approver, see Workflow Page.
Activities and Locking
To prevent multiple users from making conflicting changes, Security Manager obtains activity-level locks when a user performs certain actions within an activity or configuration session in Workflow or non-Workflow mode. This prevents two or more people from making changes to the same feature policy, policy assignment, or object at the same time.
Security Manager also uses locking to ensure that operations related to the committed configuration always run exclusive of one another. These operations can be divided into two categories:
Operations that change the committed configuration:
-
Activity approval, which includes configuration session submission in non-Workflow mode.
-
Device deletion.
-
Editing device properties.
Operations that read the committed configuration:
-
Configuration preview.
-
Deployment (in non-Workflow mode).
-
Creation of deployment job (in Workflow mode).
-
Activity or configuration session validation.
If you are performing an operation that changes the committed configuration, no one can perform any of the operations in either list until this operation is complete. An error message is displayed to the user who tries, indicating the action and activity (or user, in non-Workflow mode) that has the lock. For example, if you are approving an activity (which occurs automatically when an activity is submitted in non-Workflow mode), no one else can delete a device or validate a different activity until the approval is complete. This type of locking is particularly important in multi-user settings as it prevents multiple users from simultaneously making changes to the committed configuration.
If you are performing an operation that reads the committed configuration, no one can perform an operation that changes the committed configuration. For example, if you are validating an activity, another user cannot approve an activity. However, other users can perform another operation that reads the configuration. For example, if you are validating an activity, another user can create a deployment job. Similarly, if you are previewing the configuration before deployment, another user is permitted to do the same. This is because these two operations are limited to reading the committed configuration; they do not make any changes to it.
Tip |
Activity locking is broader in scope than policy locking, which is described in Understanding Policy Locking. Policy locking prevents two users from changing the same policy on the same device simultaneously. |
Related Topics
Activities and Multiple Users
Only one user can define or change policies within an individual activity at one time. However, when Workflow mode is enabled or when Ticket Management is enabled in non-Workflow mode, multiple users can work in the activity in sequence. That is, if an activity or ticket is closed (but not yet approved or submitted for approval), another user can open it and make changes to it if they have the necessary privileges. Multiple users can work in parallel in different activities.
Understanding Activity/Ticket States
Activities in Workflow mode and tickets in non-Workflow mode (when Ticket Management is enabled) can have the states described in the following table. The main states are shown in bold.
State |
Description |
---|---|
Edit |
The activity/ticket was created, but the activity is not currently being edited. The activity/ticket can be opened or discarded while it is in the Edit state. |
Edit Open |
The activity/ticket is open for editing. Changes, such as defining and assigning policies, can be made in the activity/ticket. The policies, policy assignments (devices being assigned policies), and objects being configured or modified in the activity/ticket are locked. That is, they cannot be configured or modified within the context of another activity/ticket. An activity can be closed, discarded, submitted, or approved while it is in the Edit Open state. A ticket can be closed, discarded, or submitted while it is in the Edit Open state. The configuration changes can be seen only in the context of the activity/ticket. |
Submitted Submitted Open |
The activity was submitted for review and approval or the ticket was submitted. (In Workflow mode, this state is available only if you have activity approval required. For more information, see Workflow Page.) No further changes can be made within the activity/ticket. The policies, devices (through policy assignment), or objects affected by the policy changes remain locked to other activities/tickets. When an activity is submitted, an e-mail is sent to the approver. The approver can open the activity (in read-only mode, moving to the Submitted Open state) to review the changes within the activity, then approve or reject it. An approved activity moves to the approved state. A rejected activity returns to the Edit state. |
Approved (Workflow mode only) |
The activity was approved, and the corresponding configuration elements are now committed policy configurations. The devices affected by the policy changes are no longer locked to other activities. The activity can be deployed while it is in the Approved state. |
Approve Failed(Workflow mode only) |
The activity is placed in the Approve Failed state if errors occur during approval (for example, due to a power failure). If this happens, try to approve the activity again or reboot the server. |
Discarded |
Changes made to the activity/ticket since it was created were discarded and further changes to the activity/ticket are not allowed. Devices associated with the activity/ticket are unlocked and can now be used in a new activity/ticket. The activity/ticket remains in the table showing a Discarded state until it is purged from the system. |
Figure 1 shows the stages in the ticket workflow. Figure 2 shows the stages in the activity workflow without an approver. Figure 3 shows the stages in the activity workflow with an approver.