This page is dedicate to gather some interest around developing a set of Integration Patterns.
Table of Contents
Contents
Goals
A way to provide an approachable way to understand what technologies are recommended by the OSLC community for various integration scenarios. These patterns can also be thought of as a way to present and share various best practices.
Definition
Patterns could cover both high-level and lower-level patterns. They identify the problem that they are addressing and scenarios where it has emerged, though not limited to. There may be multiple patterns that for various scenarios, it will be up to the end user to decide which pattern applies to their specific situation.
Usage
The intended usage if for anyone to be able to use these scenarios as a starting point to customize for their specific situation and needs. It would be ideal to link to original pattern when this is done and it indicate which patterns are used.
Pattern Catalog
The following is only a sampling/proposal on what these patterns might be (level of detail, scope, high priority)
Heterogeneous Change Management
Status: Proposed
Recommendation: TBD
Problem: More than one change management (CM) solution is often needed to track an original enterprise change request, which needs to flow to other CM tools.
Pattern: Leave the CR in the “parent” CM tool, link to a subordinate resource in another tool a work item to fulfill the request. Information about the state is fetched. State transition between the tools is the responsibility of the linked-from tool to ask the linked-to tool about changes, including state, and then take action based on that.
Scenarios:
- Enterprise change request broken down into stories+tasks in agile tool used by software development teams.
Specifications: OSLC-CM 2.0, OSLC-CM 3.0
Type: ALM, PLM
Contributors: Steve Speicher, Rainer Ersch
Continuous Delivery Pipeline
Status: Proposed
Recommendation: TBD
Problem: An automation tool will need to orchestrate automation requests(tasks) across a variety of tools such as source code extraction, compilation, packaging, deployment to test, automated testing, staging for production. There is limited traceability and consistency of interfaces between all the pipeline contributors and therefore making it costly or near impossible to determine what the input and outputs of the different automation phases are and how they relate to the overall lifecycle.
Pattern: Utilize a single pipeline server and specific tool to orchestrate the automation tasks. Utilize a consistent interface for configuring which tasks to run and with what parameters, how to execute them and how to gather the results.
Scenarios:
Specifications: OSLC-Automation 2.1/2.0, OSLC-Automation 3.0
Type: ALM, PLM, DevOps
Contributors: Steve Speicher, Martin Pain
Status: Proposed
Recommendation: TBD
Problem: A tool (the client) requires to allow the user to pick an automated process from some other tool (the server) to be exected at some point in the client’s processes. This may be immediately, or may be deferred until a later time when the user may not be present (“unattended execution”). The task may be triggered one or more times.
Patterns:
- [AEUI] Attended execution with dialog: The client allows the user to create an Automation Request resource (request for the automated task to be executed) from the server using the server’s delegated UI dialogs, and tracks the result.
- Variant: The client allows the user to choose an Automation Plan then pre-fills the Automation Request creation dialog with that plan selection, but this seems a bit pointless unless the server has not written its Automation Request dialog to be able to select an Automation Plan.
- [NOUI] Attended or unattended excution without dialog: The client allows a user to select an Automation Plan resource (an automated task definition) based on what it retrieves form the server’s query capability. It provides a form to the user to provide values for the parameter definitions that are defined in that Automation Plan (and, optionally, for the properties from the appropriate Resource Shape). At the right time(s) for the task to be executed (which may be when the user is not present) the client creates an Automation Request resource (a request for the automated task to be executed) on the server (using a Creation Factory), based on the user-supplied values, and tracks the result.
- [UEIP] Unattended execution with input parameters: The client allows the user to select an Automation Plan resource (an automated task definition) from the server using the server’s delegated UI dialogs. It provides a form to the user to provide values for the parameter definitions that are defined in that Automation Plan (and, optionally, for the properties from the appropriate Resource Shape). At the right time(s) for the task to be executed (which may be when the user is not present) the client creates an Automation Request resource (a request for the automated task to be executed) on the server (using a Creation Factory), based on the user-supplied values, and tracks the result.
- [UEAPC] Unattended execution with Automation Plan creation: The client allows the user to create an Automation Plan resource (an automated task definition) using a delegated UI dialog from the server (e.g. where they might select a “base” Automation Plan and some parameters to customize it; or where they might design an entriely new task). At the right time(s) for the task to be executed (which may be when the user is not present), the client creates an Automation Request resource (a request for the automated task to be executed) for that Automation Plan, and tracks the result.
- [UEDE] Unattended execution with ‘deferred execution’ Automation Request: The client allows the user to create a ‘deferred execution’ Automation Request resource representation (a ‘template’ request for the auotmated task to be executed, which the client then stores - unlike the previous patterns where the information was stored in an Automation Plan on the server). At the right time(s) for the task to be executed, the client uses that deferred execution Automation Request resource representation to create a copy of that resource as a new Automation Request resource on the server, and tracks the result.
This is a lot of different ways to achieve the same thing, but each has a use in diferent situations: AEUI is the basic case, when delegated UIs are available and can be used. NOUI is the only option when delegated UIs are not available on the server, or the client cannot display them (e.g. if using a CLI), or if it needs a fallback because delegated UIs don’t work for some users (e.g. Eclipse/SWT has problems with them on Linux). UEAPC is the only unattended execution case where the task’s configuration/settings are stored on the server (and so can be shared with other clients). However, Automation Plan creation dialogs are rare (in my experience), in which case UEIP is the only way to achieve unattended execution in Automation 2.0. (In contrast to UEAPC, UEIP stores the task’s specific configuration for this use - that is, the input parameters - on the client not the server, until the Automatoin Request is created). UEDE uses the ‘deferred execution’ Automation request creation dialog, which is new in Automation 2.1, but allows users to use a dialog to configure the task (which is much more flexible than input parameters, and can result in a better user experience), while also storing the task’s configuration on the client side (e.g. where it can be saved as part of a “software-defined environment”).
Scenarios:
Contributing
Add your name if you’re interested in participating or contact Steve Speicher directly
