Automation Studio Packages
Available from version 7.2
An Automation Studio package is a single file that stores components of an automation solution. When you import a package into an Automation Studio project, the components included in the package function as if they had been developed within the project itself.
Packages provide a simple and powerful way of distributing development between projects and between developers, and reusing components already developed.
Automation Studio packages can be generated from different sources:
-
Automation Studio projects: You can export one Automation Studio project as a package and then import that package into other Automation Studio projects.
-
Real-Time Designer projects: You can export a project developed in Real-Time Designer as a package and then import that package into Automation Studio projects.
-
Externally developed services (SDKs): You can develop functionality in an external development tool, such as Visual Studio, compile the service as a DLL file, and convert that into an Automation Studio package. See Create and Use Imported Services (SDKs).
Pre-built packages are available for download from the Automation Studio Resource Center.
When you import a package into an Automation Studio project, you are only creating a reference from your project to that package file. The contents of the package are not merged into your project. This means that:
-
If you later update your package, you can import the revised package into your Automation Studio project and seamlessly replace the original.
-
If the functionality provided by an imported package is no longer needed, you can remove all the components included in the package simply by removing the package from your project.
This topic provides a general explanation of how packages are used in Automation Studio. Listed below are additional topics about packages:
Guidelines on how to use packages to divide a large solution across multiple projects are provided here.
Importing Packages vs. Merging Projects
Automation Studio also allows you to merge an Automation Studio project into another Automation Studio project.
Merging a project is significantly different from importing a package. When you import a package, you are only creating a reference from the target project to the package file. It is therefore possible to remove or replace imported packages.
When you merge a project, the merged project's components are added to the target project as if they were developed there. After merging a project, there is no connection formed between the source and target project.
Why Use Packages?
There are many reasons to use Packages:
-
Promote re-use of developed components
More
Commonly used solution components can be packaged for re-use in multiple projects.
Example 1: Create all commonly used user-defined types, such as Customer or Address, in a single project. You will then be able to use those types within other projects without having to rebuild them each time. You will also be assured that those entities are described consistently throughout your business.
Example 2: Instead of building a log-in workflow in every automation project, build it in one project and import it into any other project that needs it. This not only reduces initial development time, but saves even more time if that workflow has to be modified in the future.
-
Reduce size and complexity of projects
More
Build defined components of your solution in separate projects and then import them all into a central project where each component can be treated as a black-box. Each project will be a lot smaller, and performance inside Automation Studio will be improved. Troubleshooting smaller projects is also easier.
Example: Your solution captures data an agent enters into a callout and then uses that data to populate a database, update a CRM system, and send an email. Your solution will be easier to build if you create separate projects for the database, CRM, and email operations, and import them into a central project that simply coordinates those three operations.
-
Distribute work among multiple developers
More
It is not possible for multiple developers to work on the same Automation Studio project simultaneously. However, if you divide the solution into defined components you can distribute the development of those components among multiple developers who will each work on their own project. Later, you can import their projects as packages into a single, central project.
-
Take advantage of Real-Time Designer capabilities
More
Automation Studio does not yet provide all capabilities provided by its predecessor product, Real-Time Designer. In many cases you can develop the solution components that require those capabilities within a Real-Time Designer project and then import the project into your main project in Automation Studio. When published, the solution will work as expected.
Example: You need to build a workflow that uses a library function that is available in Real-Time Designer but not yet in Automation Studio. Build that workflow in Real-Time Designer and import the project as a package into your main Automation Studio project.
What is Included in an Exported Package?
When you export a project from either Automation Studio or Real-Time Designer, all components of the project are included in the package. Some components, however, are not exposed inside Automation Studio.
Exported components that are exposed in Automation Studio can be used as if they had been created in the target project itself. They cannot be modified in the target project.
Exported components that are not exposed cannot be used or referenced directly by the target project, but will be fully functional within the published solution. More details are provided below for each component type.
The table below indicates which components are included in exported packages and which are exposed when imported into Automation Studio.
|
Component |
Included |
Exposed |
more info |
|---|---|---|---|
|
Workflows |
ü | ü | Workflows, Callouts, and User-Defined Functions |
| Callouts | ü | ü | |
|
User-defined functions |
ü | ü | |
|
User-defined types |
ü | ü | User-Defined Types |
|
Variables |
ü | û | Variables |
|
Screen elements |
ü | ü* | Screen Elements |
|
Event handlers |
ü | û | Event Handlers and Rules |
| Rules | ü | û | |
| Imported Packages | ü | û | Imported Packages |
| Data Collections | û | û | Data Collections |
Workflows, Callouts, and User-Defined Functions
All workflows, callouts, and user-defined functions that were created in the source project are listed under Imported Automation Libraries in the Assets panel below the name of the source project.
The assets of these components are all listed and can be used within the target project as if the components were created in the target project. For example, all methods, properties, and events of a workflow are listed and can be used.
Workflow steps and callout controls are not listed, and their methods, properties, and events cannot be referenced in the target project. However, if those methods, properties, and events were referenced within the source project, all related functionality will work as expected when the target project is executed. For example, if one step in an imported workflow references the Ended event of another step in that workflow, that reference will function as expected when the target project is executed.
Imported workflows, callouts, and user-defined functions cannot be edited in the target project. It is also not possible to open tabs for these components to view them.
User-Defined Types
User-defined types created in the source project are listed under Imported User-Defined Types in the Create a Complex Variable wizard. You can create variables of imported user-defined types as if the type was defined in the target project.
Imported user-defined types are not listed in the Types wizard and cannot be modified in the target project.
Variables
Variables created in the source project are not listed in the target project, and their methods, properties, and events cannot be referenced in the target project. However, if those variables, or their methods, properties, and events were referenced within the source project, all related functionality will work as expected when the target project is executed.
For example, if a workflow in the source project populates a variable that is then read by another workflow in the source project, both workflows will function as expected when the target project is executed.
Screen Elements
Screen element exposure in the target project depends on whether the source project was exported from Automation Studio or Real-Time Designer.
Exported from Automation Studio
Screen elements captured within an Automation Studio source project are exposed in the target project together with their methods, properties, and events. These assets can be used in the target project as if they had been captured in the target project originally.
Only those screen elements that were set to be available for use within the source project are exposed.
Exported from Real-Time Designer
Screen elements captured within a Real-Time Designer source project are not exposed in the target project.
However, if the screen element assets were referenced within the source project, all related functionality will work as expected when the target project is executed.
For example, if a workflow uses the Click method of a captured screen element button, that button will still be clicked when the target project is executed.
Event Handlers and Rules
Event handlers and rules defined in the source project are not exposed in the target project. However, they are operational and will perform their specified actions when they are triggered during run-time.
Imported Packages
If you export a project that itself includes imported packages to create a package, when you import that package, its own imported packages are listed as dependencies within the target project. However, you cannot remove or modify those packages.
Data Collections
Data collections in imported packages are not currently supported.
