An ACComponent can have an unrestricted number of childhood elements that are also ACComponents. This allows you to create a recursive tree structure at any depth. Each child component must have a unique name within the same list (Property ACIdentifier). This concept is similar to that of a file system. Therefore, the address of an ACComponent instance can also be uniquely identified. The address is called  ACUrl  and each ACIdentifier is separated by a backslash:

The Child-ACComponent instances are generated either:

1. Static,
2. Dynamic or
3. Program controlled.

With static instantiation, the projects are instantiated via the database, using the project tree configured in the iPlus development environment. The static instantiation happens only once during the startup process of iPlus. The trees or projects that have been assigned to the corresponding user logon are instanciated.

Dynamic instantiation is performed at any time during runtime. This is done by:

1. Loading a Workflow,
2. Opening of Businessobjects.

Explanation of the calls:

1. Method calls of the type Workflow load workflows. These add the corresponding ACComponent instances to the static tree of a project. When a workflow is processed, it is unloaded and the corresponding instances stop.
2. Businessobjects are ACComponents (derivatives of ACBSO), which are usually instantiated by the user via the user interface (for example, by calling them from the menu). Business objects are displayed in the tree below the address \Businessobjects\... is appended. The business objects are stopped also via the user interface.

Dynamic instances have the special feature that their ACIdentifier is extended with a sequential instance number during instantiation. For example, if there is a business object of the class "BSOMaterial", the first instance receives the ID 1 and thus the ACIdentifier "BSOMaterial(1)". If the user opens a second file card, the ACIdentifier is "BSOMaterial(2)".
The root instances of a workflow that is to be loaded behave in the same way. You will also receive a consecutive number. The child elements (workflow nodes) no longer require a dynamic number to be assigned, since this has already been guaranteed and specified by the workflow editor.

ACComponents are started using the StartACComponent() method. The first parameter is the class name of the ACComponent.

At startup:

1. the constructor is called first,
2. The ACInit method is called and the new instance is added as a child object to the currently calling ACComponent,
3. the ACPostInit method is called.

After these steps, you can work with the instance. If an instance is no longer needed, you can terminate it using the Stop() method:

 

In the above example, an additional check is added:

If you place a question mark "?" before the class name when calling the ACUrlCommand() method, the system first checks whether an instance already exists as a child object.

More about the life cycle of an ACComponent and the command ACUrlCommand can be read in the following subsection.

• A Root project is a type of file under which a tree of ACCcomponents can be defined and saved.
• It is comparable to a *.csproj file from Microsoft Visual Studio.
• Root projects are stored in the database in table "ACProject" and represent the root of an ACComponent tree by referring to a root class in table ACClass.
• All other child classes or instances are stored in the ACClass table. Projects are selected in the iPlus development environment using the Explorer list.
  
  There are four different types of projects:

1. Root -Project: This project represents the actual runtime. It only exists once and cannot be deleted. The Rootproject is the root of all other trees/projects. It is also an ACComponent and you can access this root instance via the Root property of the ACComponent. The children of Root are either further application projects or predefined instances (Business Objects, Communications, Environment, Messages, Queries, LocalServiceObjects and Database).
2. Application projects: You can create projects of this project type as often as you like. Here you define the instances that represent your system or automation solution when you start the iPlus service. You define which projects are to be instantiated in the user administration. The names of the application projects must be unique, since they are created directly as child elements and the Root root instance. For this reason, they are not allowed to use the pre-selected words, which are listed as predefined instances, as project names. Application projects can be derivations of so-called "application definition" projects.
3. Application Definition projects: represent an abstract intermediate layer for automation solutions. Contains base classes for the classes/Instances defined in the application projects. We recommend that you use application definitions. It helps you avoid redundant code and designs in your application projects. It also makes your end solution more maintainable, flexible and powerful in the event of changes. Application definition projects can in turn inherit from other application definition projects. Conversely, we recommend that you do not insert too many abstraction intermediate layers, as this could quickly cause you to lose your overview. As a rule, one "application definition"layer is sufficient. By the way, at least one application definition level is mandatory if you want to work with workflows.
4. If you have implemented several projects with Root , you will discover over time that you always use the same classes and composition patterns for your automation solution. Other colleagues or companies may also want to reuse their composition patterns. Here you should use the project Variolibrary. The Variolibrary project also exists only once. It contains on the one hand all classes, which have been announced via ACClassInfo attribute in the assemblies of the iPlus-Runtime and on the other hand your reusable composition patterns.