• Keine Ergebnisse gefunden

List of Algorithms

Definition 4.2: (Task Pattern) A task pattern is a reusable task structure, comprising one task with its sub-task hierarchy and the complete context information of the contained tasks such

4.6 Artifacts

composition based on task management and does not discuss collaborative authoring techniques [HRD+06]. Such authoring is considered as a peripheral activity that affects the resources associated to a given task instance. Another type of EMA can be a document, which is provided as a template from a company department and is used in various processes throughout an enterprise. Such could be e.g. an employment contract template, which is provided by a human resources department.

The user or user group, managing the artifact content, are referred to as external artifact managers. An EMA can be associated to one or more external artifact managers (cf. Figure 4.2 and 4.6), who can edit the artifact content in their workspaces and submit a consolidated EMA version to a globally accessible artifact repository. The required repository structure for storing task, artifact and human actor information and the interrelation between the different repositories are discussed in Chapter 7. For the discussion of the task management model here it is important to stress that the underlying server and repository infrastructure enables interrelation between task, artifact and user entities as described in the task instance and task pattern models.

One or more EMAs can be associated to one or more tasks. This association enables among others detection of similar tasks based on the usage of similar resources. Tasks that refer to the same EMA can be inspected for similarity towards document-based proactive information delivery and knowledge management [HRD+06].

TheEMA attributes are shown in Figure 4.8 (a). An EMA has a human-readable name and a unique identifier throughout the process composition environment. The EMA identifier and version determine the EMA content that is relevant for a given task entity. This content can be retrieved from the artifact repository by using a Unified Resource Identifier (URI), pointing at the actual location of the EMA content within the task management or associated document management system.

AnEMA artifact change entity inherits all attributes of the EMA shown in Figure 4.8 (a).

When an artifact change of typeartifact added occurs for a task all change attributes are assigned with values so that the complete information about the newly associated artifact is stored.

EMA changes of typeartifact changed preserve the original identifier attribute but may alter the dynamic attributes name, version or URI, i.e. if the EMA name or content are changed through external artifact managers. During such changes the EMA version on the artifact repository is increased and notifications are triggered to all associated tasks (instances and patterns). An owner of such a task is able to switch the reference to the updated EMA version or preserve the current EMA reference.

EMA changes of type artifact removed for a given task occur when an EMA association is removed from the task. An artifact change entity of this type stores all attributes of the removed EMA to uniquely identify the removed artifact and the concrete content (version) of the artifact that was associated with the task. Removal of the EMA association from the task does not remove the EMA from the artifact repository. Users with administrative or managerial rights can perform regularly auditing of this repository and decide whether to remove EMAs that are no longer referenced in any tasks.

4.6.2 Externalized Artifact (EA)

While EMAs enable enhanced flexibility in the document management, they require also cognitive efforts for explicitly editing and submitting artifacts to the artifact repository and for managing those artifacts. In order to ensure unobtrusiveness and in the same time to capture the document flow in ad-hoc processes, the thesis introduces Externalized Artifacts (EAs). An EA is added by an end user as a common attachment to a task instance or a task-related message in the local workspace and externalized (replicated) to a central server infrastructure. Through this the artifact is available in the global process scope beyond the personal workspace. The thesis suggests enabling externalization in an unobtrusive manner, without additional user effort by tracking user actions on task instances and messages in the local workspace and replicating task

attachments to a central artifact repository. As EAs focus above all on unobtrusive capturing of the document flow for end-user driven business process composition, they are also the primary artifact type considered in the dissertation. EAs are relevant also for task patterns. The association of the different types of artifacts in task patterns is discussed in more detail in Chapter 5.

TheEA attributes are shown in Figure 4.8 (b). During artifact externalization a single artifact copy, identified in a unique manner, is created in the artifact repository for artifacts with the same name and the same content. Thus an EA has a human readable artifact name, a unique identifier throughout the process composition environment (including artifact repository), a checksum for comparing existing EAs in the artifact repository with submitted artifacts, and a URI pointing at the concrete location of the EA content in the artifact repository. The checksum can be determined also dynamically based on the EA content and name. The checksum attribute is included explicitly in the EA attributes’ list to emphasize that during externalization equal artifact content and name result in retrieval of existing EA from the artifact repository. A new EA entry is created only if an EA with the given checksum does not exist during externalization.

The comparison of tracked artifacts with existing EAs during externalization and the reuse of the latter enable analysis of similar tasks based on the usage of similar resources analogously to EMAs. Externalization hence can enable unobtrusive detection of recurring tasks and recognition of global optimization possibilities based on usage of similar resources in dispersed, independent processes. A further consequence from task externalization is that in case of extraction of a task pattern, the latter can contain only a reference to EAs in the artifact repository. These references provide a system dependent association of artifacts within reusable task structures. As a consequence, artifacts are not provided outside of the system context and the appropriate artifact access policy. When a task pattern is reused, artifact content can be retrieved from the central artifact repository based on the unique identifier and/or URI.

AnEA artifact change entity inherits all attributes of the EA that are shown in Figure 4.8 (b).

When an artifact change of type artifact added occurs, all change attributes are assigned with values so that the complete information about the newly associated artifact is stored.

EA changes of typeartifact changed are not considered for EAs because such changes would affect the artifact name or content. These attributes determine the checksum of an EA and through this identify the EA itself. Thus, if an artifact, which was previously attached to a task and externalized, is edited by the user in the local file system and attached again, after externalization this artifact is identified as a different EA than the originally attached one. Hence, artifact changes of typeartifact change for EAs are replaced throughartifact removedandartifact added changes.

EA changes of type artifact removedremove the association of the task to an EA but preserve the EA in the artifact repository if the EA is referenced also in other tasks. If no references to the EA exist, the EA is removed from the artifact repository.

4.6.3 Locally-Managed (Non-Externalized) Artifacts

The access policy for artifacts in the artifact repository might not suffice for the privacy needs of end users in different business domains and cross-functional areas. Therefore a possibility to store artifacts in a local, non-externalized manner is considered. As shown in Figure 4.8 (c) such artifacts only have a name and a locally stored content. The latter can be embedded directly into a task (instance or pattern), e.g. as binary content. Tasks using such kind of artifacts however do not benefit from the global data distribution and unobtrusive knowledge management enabled through EAs and the additional flexibility provided through EMAs.

Artifact changes for locally-managed artifacts are limited to the artifact added and artifact removed change types because these artifacts are decoupled from the repository system and do not allow versioning and tracing of content changes.