Mit der Workflow Manager-Lizenz verfügbar.
Below are explanations of the various concepts used in Workflow Manager (Classic) and how they relate to each other.
Workflows
A workflow is a graphical representation of a business procedure that allows you to organize and standardize your process. In Workflow Manager (Classic), the workflow visually represents the collection of tasks that must be completed. The primary aim of the workflow is to ensure everyone follows the same set of steps and that steps are not missed when the task is being completed. In Workflow Manager (Classic), the workflow can be created by a user who has administrator access. The various types of workflows supported in Workflow Manager (Classic) are as follows:
- Sequential workflows
- Conditional or branching workflows
- Looping workflows
- One-step workflows
A workflow contains steps representing individual tasks, connected by paths that define the flow. Each individual task that must be completed to complete the business process is identified and created as a step type. The step types serve as the templates for steps to be used in separate workflows. Steps are instances of step types and are associated with a specific workflow. A workflow can have multiple instances of the same step type, and each of the instances can have properties configured in a different way from others. Workflow Manager (Classic) provides an easy-to-use drag-and-drop interface to drag the step types onto the workflow canvas and create workflows consisting of step instances.
The step instances determine how the task will be completed. For example, a version will be automatically created. The path determines what work will be done. For example, if a version does not exist, one will be created. However, if the version exists, the imagery is clipped.
The steps can be manual or have automated execution logic associated with them. The manual steps act as placeholders for activities that do not have associated execution logic. For instance, a documentation step in a workflow would not have any associated execution logic and would be a manual activity. Automated steps have some execution logic associated with them—they may execute custom code, start an executable, open a file, start or execute a URL, start or execute a geoprocessing tool, and so on.
The steps in a workflow have properties associated with them that determine who completes the tasks and how the workflow is executed. Steps can be assigned to a user or group to complete the task, be automatically executed when reached, and spawn concurrent steps, among other behavior. The path also has properties that are evaluated for automatically deciding what task will be completed.
Workflows must be validated before they can be saved; only a valid workflow is saved. A valid workflow must reflect the following rules:
- Only one start step
- Only one end step
- No floating steps; all steps must be connected
- Steps cannot loop to themselves
Workflows are associated with job types and are templates for the job workflows. The job workflow is an instance of a workflow template similar to a job, which is an instance of a job type. If required, workflows can be edited after jobs are created based on a system setting and appropriate privileges. However, the workflow must be committed to the database before it can be executed.
The workflows can be configured to exhibit a variety of advanced behavior and enable the automation of workflows. The advanced behaviors that can be configured are as follows:
- Automatically execute the workflow when the job is created.
- Automatically execute a series of steps after the first step is manually executed or completed.
- Execute another workflow as part of a step from within the current workflow.
Job
A job is a single unit of work that is carried out within an organization, performed by one or more people.
Steps
Step types are the building blocks of your workflows. They provide the basic information as to what happens when the step is executed and how it is represented. When a step type is added to a workflow, it becomes a step but still references all the properties of the original step type. Multiple occurrences of a step type can appear in a single workflow. The workflow steps and path display adornments to indicate information such as the type of automated step, type of notification, and path assignment. The step can also have detailed help associated to describe the step or provide instructions on how to complete it.
Job Hold
A job hold suspends all job activity until the hold is released. Holds can be beneficial in many ways, from job control to accountability and reporting. A hold prevents any job execution, along with updating of properties of a job while the hold is active. A few of these properties can be overridden with certain privileges. The information about the hold is not deleted from the job, even when the hold is released. This information can be used for determining productivity while taking into account setbacks that led to putting holds on the job.
For more information on job holds, see View and manage job holds and dependencies.
Job Dependency
Job dependencies build relationships between jobs. The execution of one job's certain step can be dependent on the status or step of another job. By defining a dependency on a job, the progression of the job is restricted at the current step until another job has progressed past a certain status. A job dependency is automatically released once the dependent job reaches the status defined in the dependency. Dependency consists of:
- Job to be held at the current step
- Dependent job
- Dependent status where the dependent job has to be at or beyond before the dependency is released
When a job is unable to progress because of a dependency, you are notified that a dependency exists and you can find out more information by visiting the Holds tab.
Hinweis:
Job Dependency is controlled through the ManageDependencies privilege. If you have the privilege, you can delete the job dependency and proceed with the job workflow without being held by another job. For more information on job dependency, see Dependencies.
Location of interest
The location of interest (LOI) represents the geographic extent of the job. Its purpose is to highlight where the work related to the job needs to be done. The location of interest for a job can be a polygon or point, and the LOIs for all the jobs are stored in a respective polygon or point feature class in the Workflow Manager (Classic) repository. The polygon extent of the job is called the area of interest (AOI), and the point extent of the job is called the point of interest (POI).
The template map used for defining the LOI is created by an administrator and stored in the job type. The template map specific to the job type displays in a map view when the Define LOI step is executed. The Define LOI tab provides many ways to define an LOI for a job. Defining an LOI is a privilege-based activity and can be performed only by those who have the required privileges. The LOI for a job can be one or many multipart features. The AOI can be used to restrict the edits being done for a specific job to a geographic area.
If an LOI is already defined for a job, it can be accessed as a bookmark within the Define LOI map or a map opened from a Workflow Manager (Classic) step. The bookmarks can be accessed from the map view tab and the Bookmark pane. When an LOI bookmark is clicked, the map zooms to the defined location of interest for the job.
For more information on defining the location of interest for a job, see Specify a location of interest (LOI).
Hinweis:
Exported ArcGIS Pro maps (.mapx) configured using Workflow Manager Administrator 10.5.1 and later can be used as template maps for defining LOIs in ArcGIS Pro 2.0 and later.
Users and groups
Users represent registered individuals within the Workflow Manager (Classic) database and are associated with a specific Windows, Portal for ArcGIS, or ArcGIS Online login so that they are authenticated automatically. Users are key to controlling what work is available and how it is run, assigned, and reported on. They are used for the following:
- Allowing/Denying access to the application
- Retrieving database connection information
- Controlling access to specific application functionality
- User-stamping history
- Assigning work to individuals
User groups are used to categorize users for many reasons, specifically to assign privileges or roles, but also to classify users for the purposes of assigning work. You can associate multiple groups with each user. This allows you to associate privileges (that are assigned to groups) with users by combining groups.
Spatial data workspace
A spatial data workspace contains spatial data that will be used while executing the job. A job can have only one data workspace associated with it at a given time. You can switch data workspaces to work on data stored in multiple databases during the life cycle of a job. The spatial data workspace can be configured as a geodatabase with traditional versioning. It can also be configured as a feature service with branch versioning.
Version
The Workflow Manager (Classic) system automatically manages versions. You can perform actions including checking versions, creating versions, repointing layers to a specific version, and deleting versions.
Workflow Manager (Classic) supports both traditional versioning and branch versioning, and allows multiple users to edit data in their own version.
In a traditional versioned data workspace, the data stored in a geodatabase can be edited by multiple users. Each job creates the job version, and data can be repointed to the job version. Data edits specific to the job are made in the job version. Once the edits have been completed, the version may be reconciled and posted back to the parent version.
Workflow Manager (Classic) supports branch versioning with the same level of management as traditional versioning. Only the data layers coming from the feature service data workspace are repointed to the job version.
For more information about versioning, see Overview of versioning.
Job history
When a new activity has been performed on a job, such as creation, reassignment, step execution, or workflow modification, among others, the history log is automatically updated with the date/time stamp, the user who performed the activity, and information regarding the activity itself.
Extended properties
Extended properties are custom properties that enable you to store business-specific properties as required. These properties are configured by job type, as it is likely that different types of work require different properties associated with them. The custom extended properties display on the job view with Extended Properties as the default title. This may appear by another name, depending on the job type configuration. You can view and update (where applicable) the one-to-one properties here. The one-to-one properties have only one record for each job in the extended property table.
Notifications
Notifications are email alerts triggered by events in the Workflow Manager (Classic) system throughout the life cycle of the job. Notifications provide a way for users to work confidently without worrying about missing job assignments or failing to meet required job correspondence. Some examples of built-in notifications are as follows:
- Job is assigned or reassigned
- Job created
- Job closed
- Step execution completed
- Hold released
- Extended properties updated
The notifications can be sent using a SendNotification automated step or as part of an existing step, to be sent once the step is complete. The notifications are sent to the subscribed Workflow Manager (Classic) users only. Tokens can also be used to dynamically send notifications to the appropriate user, even though it is not known who should receive the notification at the time of notification configuration. The job attachments can be included in the email notification as well to provide more information about the job to the receiver. You may add new notifications as required, and use them in your workflows without any programming. The configuration of notifications and assignment of subscribers can be done by an administrator only.
Hinweis:
For notifications to be sent, the SMTP server for the system must be configured. The SMTP settings are defined in the system settings in Workflow Manager Administrator. However, once applied, these settings are consumed by ArcGIS Pro.
Offline jobs
Offline jobs allow you to use workflow management capabilities when disconnected from your organization's network. The benefit of working with offline jobs is that you can complete tasks assigned to you when in the field or off the network. When you take a job offline, all the necessary configuration elements required for the job to work in the offline mode are taken offline as well, and the offline jobs are represented by a red icon. Offline jobs can still be used by queries, but they cannot be executed or worked on in an enterprise environment until brought online. Offline jobs have almost all of the functionality available with online jobs.
Suspend execution
The execution of a long-running mapping step and manual steps can be suspended to accommodate longer editing time, as well as the work being performed outside of ArcGIS spanning hours or days with breaks in between.
The mapping step can be suspended only when it is not configured to proceed to the next step automatically. The step can be suspended from both the job view and the map view using the Suspend Step option when the step execution is in progress. In the job view, the step execution progress displays when the mapping step executes. In the map view, the Suspend option is presented when you try to close the job map.
The manual step can be suspended within the job view using the Suspend Step option when the step executes to indicate that it has been started and the execution is in progress.
Hinweis:
Currently, manual steps cannot be restarted if suspended.