Business Applications

A business application is a collection of components that provides a business functionality that you can use internally, externally, or with other business applications. You can create business applications of individual components, which are related to each other.

For example, Order Management, Inventory Management, and Billing are business applications that might use individual components such as a Java EE application server, LDAP, and a database that runs on the Solaris server.

Business application is a type of a custom collection. You can also create the following types of custom collections:
  • Collection, which is a group of any resources that you can select according to your needs.
  • Access collection, which is a collection that is used to control the access to configuration items (CIs) and permissions to modify configuration items. You can create access collections only when data-level security is enabled.
The following methods are provided for creating business applications:
  • By using grouping patterns in Data Management Portal.
  • By using application descriptors.
  • By using grouping patterns that are created with Java API and loaded by the bulk load program.

Business applications in the previous TADDM releases

In the previous TADDM versions, a business application was a flat collection of unconnected CIs. These CIs could be only top-level elements of Common Data Model. They were grouped into functional groups of elements of the same type. Each CI had to be explicitly added to a business application, either as an instance, or by using an MQL rule. It required the user to know exactly which elements formed the business application and what dependent objects the user should include into the business application.

New approach to generate business application by using grouping patterns

With this TADDM release, the approach to creating business applications radically changes. A business application is now a graph of connected CIs of types that you specify. The most important elements while building business applications are core CIs. Core CIs provide main business value to the specific business application, for example, Java Platform, Enterprise Edition application, or a database. They are the only elements that you must add manually (either by MQL or SQL query, a set of CI instances, or as application descriptor files), or by using API (in case of integration scenarios). All other elements that constitute supporting infrastructure for a business application are added automatically by traversing relations and dependencies that are discovered and stored in TADDM. You can decide which relations are traversed and which are skipped. You can also decide which CIs from all traversed objects are used to compose the resulting business application.

As you cannot be sure that all necessary dependencies are already discovered and stored in TADDM, or because there can be dependencies that have strictly business meaning and cannot be automatically discovered, you can specify more than one core CI for each business application. You can either create many queries to select multiple core CIs, or you can use CustomSqlDependencyAgent to create more dependencies between related objects. If you use the agent, you do not have to create more queries.

A grouping pattern consists of queries that select core CIs, the formula that calculates the name of business applications from the core CIs, and a description that defines the way that the dependent objects are traversed. Grouping patterns are processed automatically according to the schedule that you define and custom collections are generated as a result. Each time a grouping pattern is processed, all queries are processed, all dependencies are traversed, and the business application structure is generated according to the existing CIs and relations. As a result, all environmental changes to the structure of the business application are automatically captured and reflected when the grouping pattern is processed. For example, if a new application server, or a new virtual machine is discovered, it is added automatically to the business application. If a CI was modified, or removed, for example a virtual computer system was moved to another hypervisor, the changes are automatically applied, that is the virtual computer system is removed from the application that contained the hypervisor.

In the previous releases, one application template could produce only one business application. Now you can create not only one business application from one grouping pattern, but you can also create many business applications from one pattern, or a small set o patterns. As a result, it is easy to generalize grouping patterns to produce instances of business applications for multiple environments, for example, the application deployed in production, test, quality assurance, and performance environments. To achieve it, a grouping name expression was created. You can use it to provide a formula to calculate the name of a business application from its core CI. For example, you can use naming conventions to extract specific parts of CIs names, or any existing attributes that denote the purpose of a specific environment. You can also extend this generalization. For example, you can create a grouping pattern that generates all business applications of a given type, such as Java Platform or Enterprise Edition applications, in all deployment environments.

For more information about grouping patterns configuration and controlling grouping patterns processing, see Processing of grouping patterns.

Note: Business applications that are created with the default configuration contain only high-level and middle-level objects. Therefore, some CI types, which were high-level objects in TADDM 7.2.2, are no longer high-level objects in version 7.3.0. As a result, they are not added to business applications. The new high-level objects are SComputerSystem, SSoftwareServer, SLogicalGroup, SPhysicalFile, SSoftwareInstallation, SFunction. The new middle-level object is SDeployableComponent. Additionally, in the new model, there is no OperatingSystem type, its attributes were merged into the simple.SComputerSystem class.