subapplication modeling

If you model subapplications, keep in mind that you must only model subapplications when the role or the authorization that you want to link or assign to the subapplications is different from the role or authorization linked to the application that is linked to the activity.

You can only link subapplications to an activity in a business process in the repository. You can however, link a role to a subapplication in the repository and in a project model.

When you model subapplications, restrict authorization on the highest level possible, as all modeled subsapplications that can be started from a modeled (main) application inherit the authorization from the (main) application. This means that you must model subapplications that are started from

the (main) application and subapplications that are started from subapplications. The higher the restrictions are modeled, the more child-subapplications will inherit the restricted authorization.

If a role is linked to a main business process, the subprocess inherit that role. The role becomes valid, when the subprocess is used in the context of the main business process. When the subprocess is used in another main business process, other roles can become valid.

Inherited roles are not directly linked to the subprocess. So when a business process that is used as a subprocess is opened in the Enterprise Modeler Editor on its own, and not from the main business process, those inherited roles will not be known. These roles are, however, valid in the context of that business process.

The following table provides the authorization codes and their descriptions. Use, for example, VI for Unix, or Notepad for Windows NT to create a file that contain subapplications and their authorizations.