Creating service blueprints

You can create a blueprint in one of the following ways:

• By using the available configuration items (CIs) and their relationships: Use this method if you have limited knowledge of the CIs in the infrastructure for which you are creating the blueprint.
• By using available CI kinds and establishing relationships between them: Use this method if you have complete knowledge of the CIs in the infrastructure for which you are creating the blueprint.
• By using a combination of CIs and CI kinds, and establishing relationships between them.

Before you begin

Before you start creating a blueprint, perform the following tasks:

• Discover CIs through BMC Helix Discovery or any other supported data ingestion mechanism such as API calls. For more information, see the BMC Helix Discovery  documentation.

• Understand the CIs and their relationships that are present in the infrastructure for which you want to create a blueprint. For example, if you want to create a blueprint for a Kubernetes-based application, understand the namespaces, clusters, and deployments, and relationships between them.
• Identify the start node for a blueprint.

Sample blueprint for the Kubernetes applications

The following figure illustrates a sample blueprint, Kubernetes Infrastructure Blueprint, which represents the Kubernetes infrastructure. You can use the blueprint to create business services to monitor Kubernetes applications, for example, Train Ticket Management System. This application is used to manage train reservations. 

The sample blueprint for the Kubernetes applications contains the following information:

• Start node: Is a node of Namespace type.
• Default CI rule on the start node: Contains the following information:
  • Default filter criteria set on the start node: Indicates that the name of the namespace is added as a variable. This variable provides you the flexibility to specify the namespace name while creating a service by using the blueprint. According to the specified name, the entire service topology will be populated.
  • Content of the namespace is required and must be included while creating a service by using this blueprint.
• Link rules: Indicate the relationship rules between different CI kind nodes. For example, the Collection rule between the Namespace and Deployment nodes indicates that only those deployments that are members of the namespace are considered when a service is created by using the blueprint.
• Traversal path and connected nodes: Are associated clusters, deployments, software pods, and hosts.

Use the steps described in the following procedure to create this blueprint.

To create a blueprint by using the available CIs and their relationships

Use the available CIs and their relationships to create a sample blueprint, Kubernetes Infrastructure Blueprint, which is described in the previous section.

1. Select Configurations > Manage Service Blueprints.
2. On the Service Blueprints page, click Create Service Blueprint.
3. Specify the name, description (optional), and provider (domain) details for the blueprint.
   For example, Kubernetes Infrastructure Blueprint, v1, itbiz.com.
   
4. On the Select CIs tab, add CIs:
   1. Click + Add CIs.
      The Add CIs page displays a list of categories and subcategories, by which you can easily search for the CIs that you want to add.
      By default, CIs are displayed for the Host and Host Containers category and the Hosts subcategory.
   2. Search for the required CIs by performing one of the following actions:
      
      • Type the name of the CIs (minimum three characters).
      • Select another category and subcategory.
        For example, to add a namespace CI, select the Cloud & Container Orchestration category and the Namespace subcategory.
   3. Select one or more CIs (for example, ticketing) to add them to the blueprint. 
      The ticketing CI represents the Kubernetes namespace.
   4. Scroll down to see the Include Related CIs check box.
      When you select only one CI, the check box is selected by default, which indicates that all the related CIs of the selected CI will also be added.

   5. (Optional) Clear the check box if you don't want to add the related CIs.
      

      
      

      Important

      If you select multiple CIs, the Include Related CIs check box is disabled, which means that you cannot add multiple CIs with their related CIs at the same time. However, you can add multiple CIs without their related CIs at the same time. If you want to add multiple CIs with their related CIs, add one CI and its related CIs at a time. 

   6. Click Add and then click Close.
      Because you have selected the Include Related CIs check box for the ticketing CI, its relationship with other CIs is also shown.
      

      
      

   7. (Optional) Set the blueprint display option as either Organic or Hierarchic (default).
      In the organic view, nodes are placed close to their adjacent nodes, thus saving space. While, in the hierarchic view, the nodes are distributed into layers. This view facilitates the identification of dependencies and relationships among the nodes.

5. Click Next Step.
   Based on the selected CI (ticketing) in the previous step, its CI kind (Namespace) is displayed as the start node. Because you have selected the Include Related CIs check box in a previous step, its relationship with other CI kinds, which are represented by other nodes, is also displayed.

   

   In addition, a default rule is added to the start node and link rules are added between different nodes.

   • Default CI rule on the start node: Contains the following information:
     • Default filter criteria set on the start node: Indicates that the name of the namespace is added as a variable. This variable provides you the flexibility to specify the namespace name while creating a service by using the blueprint. According to the specified namespace, the entire service topology is populated.
     • Content of the namespace is required and must be included while creating a service by using this blueprint.
   • Link rules: Indicate the relationship rules between different CI kind nodes. For example, the Collection rule between the Namespace and Deployment nodes indicates that only those deployments that are members of the namespace are considered when a service is created by using the blueprint.
6. (Optional) Edit the default CI rule, or add more CI kinds, CI rules, and link rules if this blueprint does not meet your blueprint requirements.
   For information about adding CI kinds, CI rules, and link rules, see To create a service blueprint from CI kinds.

1. Click Next Step to preview the blueprint.
2. Select the name of the namespace (for example, ticketing) in the right pane.
   The left pane shows the blueprint preview according to the selected namespace. By default, nodes of the same CI kind are grouped.

3. (Optional) Use Disable grouping by CI Kind to ungroup the nodes.

4. Click Save to save the blueprint.
   The blueprint is added to the list of blueprints available in BMC Helix AIOps. By default, the newly created blueprint is not displayed on the Service Blueprints page.
   

   Important

   By default, the newly created service blueprint is disabled. To create a service by using a blueprint, you need to enable it. For more information, see Actions available on service blueprints.

When you create a service by using the Kubernetes Infrastructure Blueprint, the service topology is populated according to the namespace you provide as input. For example, the service topology of the Train Ticket Management System application looks like the following example when you provide the ticketing namespace as the input.

For more information about creating a service by using a blueprint, see Defining-a-service.

Sample blueprint for the AppDynamics applications

The following figure illustrates a sample blueprint, AppDynamics Application Infrastructure, which represents the AppDynamics application infrastructure. You can use the blueprint to create business services to monitor AppDynamics applications, for example, Retail Outlet. This application is used to manage outlets in a retail chain of restaurants. 

 The sample blueprint for the AppDynamics applications contains the following information:

• Start node: Is a node of Software Cluster type.
• Default CI rule on the start node: Contains the following information:
  • Default filter criteria set on the start node: Indicates that the name of the software cluster is added as a variable. This variable provides you the flexibility to specify the cluster name while creating a service by using the blueprint. According to the specified name, the entire service topology is populated.
  • Content of the software cluster is required and must be included while creating a service by using this blueprint.
• Link rules: Indicate the relationship rules between different CI kind nodes.
• Traversal path and connected nodes: Are associated software clusters, software components, software instances, and so on.

Use the steps described in the following procedure to create this blueprint.

To create a service blueprint by using CI kinds and establishing relationships between them

Use the CI kinds and establish relationships between them to create a blueprint, AppDynamics Application Infrastructure, which is described in the previous section.

• Task 1: Provide blueprint details
• Task 2: Add CI kinds and establish relationships between them
• Task 3: Define CI rules for the start node and other nodes
• Task 4: Preview and save the blueprint

Task 1: Provide blueprint details

1. Select Configurations > Manage Service Blueprints.
2. On the Service Blueprints page, click Create Service Blueprint.
3. Specify the name, description (optional), and provider (domain) details for the blueprint.
   For example, AppDynamics Application Infrastructure, V1, itbiz.com.

Task 2: Add CI kinds and establish relationships between them

1. Click Next Step to skip the Add CIs step and start creating the blueprint by adding CI kinds.

2.  Add CI kinds and establish relationships between them by dragging one CI kind towards another.
   For example, add Software Cluster, Software Instance, and Software Component. For the list of CI kinds and relationships that you can add to a blueprint, see Supported CI Kinds and relationships.
   

   Important

   You might see error icons above CI kinds indicating that there are multiple start nodes. These errors are resolved automatically after you establish relationships between CI kinds in the next step.

3. Add more CI kinds according to your requirements, such as Network Interface, Virtual Machine, and Host, and establish relationships between them as shown in the following figure:
   
4. After establishing relationships, make sure that there is only one start node.
   Multiple start nodes are indicated by an error icon above the CI kind nodes.
5. (Optional) Assign any other node as the start node.
   For example, if you want to start with the Software Cluster node, you can assign it as the start node.
   1. Select the CI kind that you want to assign as the start node.
   2. On the Define CI Rule page, click Specify Blueprint Start Node Kind.
      When you assign any other CI kind as the start node, the blueprint is automatically re-computed.
6. To change the list view, from the Available CI Kinds section, select view as icons or view as type .

7. (Optional) Set the blueprint display option as either Organic or Hierarchic (default).

Task 3: Define CI rules for the start node and other nodes

1. Define the CI rules for the start node.
   1. Click the start node.
      On the Define CI Rule page, the default filter criterion shows the Name attribute of a CI added as a variable. When creating a service by using this blueprint, you need to provide this attribute as the input. In the sample blueprint, the name of a software cluster is set as a variable.
   2. (Optional) Change the CI kind from the list by selecting one or more node kinds.
   3. Include (default) or exclude the content of a CI Kind.
      You can exclude the content of a CI kind and keep only the related nodes as part of a blueprint.
   4. Make sure that the Required Content check box is selected to indicate that content (CIs) must exist for the CI kind of the start node in BMC Helix Discovery.

   5. (Optional) Edit the default filter criterion:

      1. On the Define CI Rule page, select Edit from Action.
      2. On the Define Filter page, select Edit from Action. 
      3. Clear the Set as variable check box if you don't want to set the default attribute, Name, as a variable.
         The filter criterion of a start node must have at least one CI attribute set as a variable. You can set up to three attributes as variables in a blueprint, including one mandatory variable for the start node. 
      4. Update the message in the Define user prompt message text box if needed.
         For example, replace the existing message with the following message: Select the Cluster App name
      5. Select any other CI attribute for the default filter criterion:
         • Select a named CI attribute.
         • Select an extended CI attribute.
           To view extended CI attributes, from Actions , select Use Extended Attributes.
   6. (Optional) Add more filter criteria to the start node:
      
      1. On the Define CI Rule page, select Edit from Action.
      2. On the Define Filter page, select Edit from Action. 
      3. Click Add New Filter Criteria.
      4. To set a CI attribute as a variable, click Set as variable and update the message in the Define user prompt message text box if needed.
         You can set up to three attributes as variables in a blueprint, including one mandatory variable for the start node. When creating a service by using this blueprint, you need to provide these attributes as inputs.
      5. (Optional) If you don't want to set a CI attribute as a variable, perform the following steps to select a CI attribute and its value:
         1. Select a named CI attribute (for example, key) or an extended CI attribute.
            To view extended CI attributes, from Actions , select Use Extended Attributes.

1. 1. 1. 1. Select the CI attribute value from the right pane or enter a regular expression. 
            For example, enter APPDYNAMICS.* as the regular expression so that when you create a service by using the blueprint, the service topology contains only the clusters whose key starts with APPDYNAMICS.*.

   2. Click Save and Close.
   3. Save and close the Define CI Rule page.
2. Define the CI rules for other nodes.
   1. Select the CI kind node (for example, Software Cluster) for which you want to define the CI rules. 
   2. (Optional) On the Define CI Rule page, change the CI kind from the list by selecting one or more CI kinds. 
   3. Include (default) or exclude the content of a CI kind.
      You can exclude the content of a CI kind and keep only the related nodes as part of a blueprint.
   4. Select the Required Content check box to indicate that the content (CIs) must exist for the CI kind of the node in BMC Helix Discovery.
   5. To add a filter, click Add New Filter.
   6. On the Define Filter page, click Add New Filter Criteria.
   7. To set a CI attribute as a variable, click Set as variable and update the message in the Define user prompt message text box if needed.
      You can set up to three attributes as variables in a blueprint, including one mandatory variable for the start node. When creating a service by using this blueprint, you need to provide these attributes as inputs.
   8. (Optional) If you don't want to set a CI attribute as a variable, perform the following steps to select a CI attribute and its value:
      1. Select a named CI attribute (for example, Name) or an extended CI attribute.
         To view extended CI attributes, from Actions , select Use Extended Attributes.
      2. Select the CI attribute value from the right pane or enter a regular expression.
         For example, if you want to filter the AppDynamics applications only with the names Pricing and Inventory, enter Pricing and then Inventory in the Value field and select them.

3. Click Save and Close.
   The Define CI Rule page shows the filter criterion.
4. Save and close the Define CI Rule page.
   The CI kind node shows the filter icon.
5. (Optional) Define rules on the relationships between CI kinds.
   For example, add the Communication rule between Software Cluster and Software Component. This rule indicates that the software cluster must be communicating with the software component.
   1. Click the link between the CI kinds.
   2. On the Define link page, select Filter by Kind.
   3. From the relationship type list, select Communucation.
6. Similarly, add the Hosted Software rule between Virtual Machine and Host, as shown in the following image:
   
   
7. If you observe any errors on any of the CI kind nodes, resolve them.
   For more information, see To resolve errors that occurred while creating service blueprints. 

Task 4: Preview and save the blueprint

1. Click Next step.
2. Select the name of the cluster (for example, Retail-Outlet) in the right pane.
3. If you have added CI attributes as variables in the filter criterion of other nodes, select the attribute values in each step in the right pane.
   The left pane shows the blueprint preview according to the selected cluster name. By default, nodes of the same CI kind are grouped.

4. (Optional) Use Disable grouping by CI Kind to ungroup the nodes.

5. Click Save to save the blueprint.
   The blueprint is added to the list of blueprints available BMC Helix AIOps. By default, the newly created blueprint is not displayed on the Service Blueprints page.
   

   Important

   By default, the newly created service blueprint is disabled. To create a service by using a blueprint, you need to enable it. For more information, see Actions available on service blueprints.

When you create a service by using the AppDynamics Application Infrastructure blueprint, the service topology is populated according to the software cluster name you provide as the input. For example, the service topology of the Retail Outlet application looks like the following example when you provide the Retail-Outlet cluster as the input.

For more information about creating a service by using a blueprint, see Defining-a-service.

For more information about creating a service by using a blueprint, see Defining-a-service.

To resolve errors that occurred while creating service blueprints

When you see an error icon above a CI kind, hover over the CI kind for the tips  and based on the error tips, perform one of the following actions:

• Make sure that there are no unconnected nodes. There must be only one start node in the model.
• If there is only one start node with an error icon, perform the following steps:
  1. Click the node to display the Define CI Rule page.
  2. Either select Add New Filter > Add New Filter Criteria to add filter criteria or select Edit > Edit to edit filter criteria.
     You can add only one filter to a root node and a maximum of three filters to the subsequent nodes.
     
     1. Click Set as variable and type a message in the Define user prompt message text box.
        You can set up to three attributes as variables in a blueprint, including one mandatory variable for the start node. When creating a service by using this blueprint, you need to provide these attributes as inputs. 
     2. Select a named attribute.
     3. (Optional) Select an extended attribute:
        1. From the Actions menu, select Use Extended Attributes.
        2. Select extended attributes from the displayed list.
  3. Save and close.
  4. Save and close the Define CI Rule page.
     The error message on the node disappears.

Actions available on service blueprints

On the Service blueprints page, click the Action menu  to perform actions based on your requirements. 

Where to go from here

To learn how to create service models by using service blueprints, see Creating-service-models.