Some models consist of a single assembly of parts that you can modify to create different variations of the same model. With the Intent solution, you can open a model and use different parameters to create different variations of it.
The top-level design contains the child rules that include the necessary parts of the staircase, and the parameter rules for customizing the staircase. When they create an assembly using the solution, the assembly already contains a single staircase. They can modify the parameters to specify the height, diameter, material, and so on, to meet their requirements.
In many situations, you cannot determine ahead of time the parts and subassemblies in the final design. For example, consider a company that designs consoles for control rooms and operation centers. Each customer has unique requirements that necessitate unique designs and solutions. One customer requires one small console with space for three operators and their associated equipment. Another customer requires multiple consoles of various designs to accommodate a large number of people and equipment.
In this type of solution, it is impossible for the Inventor ETO solution author to anticipate every possible configuration. The top-level design does not include all of the necessary child rules, because there is no typical solution. It requires a more flexible solution than for single models.
When you build models with multiple, configurable parts and subassemblies, the Intent author builds a solution in which you interactively add children to the top-level assembly. In this solution, the top-level Intent design includes parameters that pertain to the overall design, such as customer information, material type, and so on. It does not contain all of the necessary child rules. Therefore, when you start a new assembly using the top-level design, the assembly is empty. You add the required designs by dynamically adding child rules to the assembly file, selecting from designs that are made available by the solution author.
The application architecture for desktop and web applications should isolate the UI from the application. The application built on full Inventor should run without an addin. Don't mix addin code with business logic. Business logic should be driven from Intent rules/dlls.
The server API is a subset of the full API. APIs that require the UI/Viewer (i.e. View, Ribbon, CommandManager) are typically not supported. To support Server based applications, these APIs should not be a critical piece of your ETO application.