This article describes how to find dependencies on other application packages with AppWorks Platform (Process Platform).
In general, deploying an application often requires other applications to already be available at the target environment. Applications developed with the AppWorks Platform (Process Platform) can also have inter-application dependencies. Within AppWorks Platform application packages, this is administered as packages dependencies. Package dependencies prevents you from encountering many kinds of run-time issues while running your application.
Applications may include dependencies on other application packages. Refer to this article for How To: Install an application. When trying to install an application that depends on an artifact delivered as part of another application, you can run into different scenarios:
In the first scenario, the required application is not yet uploaded and therefore not available for installation. Installing your application is then blocked. This is shown in the below screenshot.
Once all required application are uploaded as well, the system ensures that the required applications are deployed before deploying the application of your interest.
Package dependencies can be introduced in many different ways. Two different types of dependencies, namely source dependencies and binary dependencies, are described below. Run-time references can only be created for components of applications that are deployed on the development environment.
Source dependencies are introduced when design-time artifacts of one application are using design-time artifacts of a different application. For example, by using a role of one application as a sub-role of a different application; or by using a user interface of one application in a business process of a different application.
You can only have a source dependency on an application of which you have the design-time artifacts.
There are a number of scenarios when the application uses third party libraries or application components. Typically, these sources are then not available. When these artifacts are delivered through AppWorks applications, the AppWorks platform enables you to use those application components through run-time references. For every run-time reference that is included in the application, a package dependency on the application package is introduced. Run-time references can only be created for application components that are deployed in organization-independent repositories. Application components that are only deployed in organization-specific run-time repositories may not be available for all organizations and can therefore not be reused.
You can also have binary dependencies on applications of which you do own the sources. For this, you need to deploy those applications on the development environment.
During application development, you can introduce source dependencies. For example, when moving a design-time artifact from one project to another project may produce a source dependency. This mainly depends on whether that artifact is used by other artifacts enclosed in its original project. Once you run into unexpected package dependencies when deploying your application, there are several ways to start analyzing package dependencies:
Before you start analyzing package dependencies, first make sure whether the required application originates from the same workspace as the application you are trying to deploy. If not, the package dependency can be identified by the first alternative.
The most straightforward way to analyze unexpected package dependencies is by determining whether the originating project includes run-time references to artifacts provided by the required application. First of all, creating a run-time reference requires some explicit actions to be taken. Therefore, you or other members of the development team will likely remember this. Next, if you have structured your project well, you should be able to easily find whether or not a run-time reference is producing the package dependency. If the project is not structured well, you can still go through all - including nested - folders to be sure that the unexpected package dependency is not due to a run-time reference.
Note that when reusing run-time references from other projects, this also introduces package dependencies on those projects.
In cases where the unexpected package dependency is not due to a run-time reference, the dependency must be a source dependency. For arbitrary design-time artifacts, there is an option to list its consumers using the Used-By functionality.
For example, assume your application includes two roles such that one is a subrole of the other. If you then perform the Used-By query on the subrole, this will produce a list including the other role.
Now assume, your workspace has the below depicted structure:
In this example, the workspace contains three projects (or applications):
The idea is that the business process "Update Customer" is using webservices provided by the application MyDataServices. All roles and user interfaces used in this business process are included in the same application as the business process. The business process "Upgrade Customer" is using webservices provided by the application MyDataServices, and the business process "Update Customer" as a sub process and other webservice. Again, all additional roles and user interfaces used in "Upgrade Customer" are included in the same application.
As a result, there are the following package dependencies:
These dependencies become visible by using the Used-By query on each of the applications. For example, the result of the Used-By query on MyDataServices is shown in the below picture.
Similarly, the Used-By query on MyCoreApplication indicates that some application component is used by the business process "Upgrade Customer" of MyCustomApplication.
You need to sign in before voting.