Conceptual Model Editors

For an action code, leave this row blank if the data element is not required by the action.

For service actions, only persisted data elements are added to Inventory specifications when you realize the conceptual model entity. See "Conceptual Model Editor Categorization Tab" for information.

• Required In: the data element value must be supplied for the associated action.

• Required Out: the data element value must be returned by the associated action.

• Required In/Out:: the data element value must be supplied for and returned by the associated action.

• Optional In: the data element value can be optionally supplied for the associated action.

• Optional Out: the data element value can be optionally returned by the associated action.

• Optional In/Out: the data element value can be optionally supplied for or optionally returned by the associated action.

• Blank: the data element is not applicable to the action.

See "Extending Design Studio Entities" for more information.

• Select None if the conceptual model entity will not be realized as an application entity. You select this option, for example, if the conceptual model entity is intended for informational use only.

• Select Unified Inventory Management if the conceptual model entity will be realized as an entity used in the Design Studio for Inventory application.

• Select Other System if the conceptual model entity will be realized as an application entity that will be used in a system other than Unified Inventory Management.

Note: The design patterns that are delivered with Design Studio and that realize the conceptual model entities add configuration to your workspace only if you define this field with the Unified Inventory Management value.

If you change the value in this field and re-run a Design Studio default design pattern, the design pattern does not delete any previously generated entities.

See "Realizing Conceptual Model Entities into Application Entities" for information about how each conceptual model entity realizes.

• Save of the editor of the conceptual model entity.

• Change the conceptual model entity using an option that you select from the context menu.

• Manually synchronize or realize a direct child of the conceptual model entity. For example, when this option is selected, Design Studio automatically runs a design pattern for an RFS if you manually synchronize a child resource.

See "Synchronizing Conceptual Model Entities with Application Entities" for more information.

Do one of the following:

• Click Select to associate an existing fulfillment pattern to the conceptual model entity.

• Click Add to create a new fulfillment pattern and associate the new fulfillment pattern to the conceptual model entity.

• Select a value and click Open, which opens the fulfillment pattern in the Fulfillment Pattern editor.

• Select a value in the Fulfillment Pattern field and click Remove to remove the association between the fulfillment pattern and the conceptual model entity.

The default value for this field is the name of the entity. You can define a different key value for an entity if your business processes require a naming convention less restrictive than then entity name requirements.

You must tag a data element with the Characteristic tag (in the data schema) to add it to an Inventory Service specification during realization.

When realizing customer facing services and resource facing services, the default design patterns save data elements that are tagged as Changeable to the Service Configuration specifications.

You must tag a data element with the Persisted tag to add it to an Inventory Service specification during realization. Data elements that are tagged as Changeable and Persisted, and structured data elements that are tagged as Persisted are added to the Configuration specification during realization.

Do one of the following:

• Click Extends to create and extend a new source product.

• Click Select to extend an existing source product.

Do one of the following:

• Click Select to associate an existing fulfillment pattern to the product.

• Click Add to create a new fulfillment pattern and associate the new fulfillment pattern to the product.

• Select a value in the Fulfillment Pattern field and click Open to open the fulfillment pattern in the Fulfillment Pattern editor.

• Select a value in the Fulfillment Pattern field and click Remove to remove the association between the fulfillment pattern and the product.

The default value for this field is the name of the entity. You can define a different key value for an entity if your business processes require a naming convention less restrictive than then entity name requirements.

Click the Application Role link to open the application role in the Application Role editor.

You can add or remove Specialized Action Name and Action Code pairs.

The action codes available to add to the action are defined on the functional area associated with the application role (specified in the Action Type field). For example, when modeling technical actions, you can add any action code defined on the Technical functional area.

Click the Action Code link to open the action code in the Action Code editor.

The default value for this field is the name of the entity. You can define a different key value for an entity if your business processes require a naming convention less restrictive than then entity name requirements.

• Select None if the action will not be realized as an application entity. You select this option, for example, if the action is intended for informational use only.

• Select Unified Inventory Management if a service action will be realized as an entity used in the Design Studio for Inventory application.

• Select ASAP if the technical action will be realized as an entity used in the Design Studio for ASAP application.

• Select Other System if the action will be realized as an application entity that will be used in a system other than Unified Inventory Management.

Note: The design patterns that are delivered with Design Studio and that realize the conceptual model entities add configuration to your workspace only if you define this field with the Unified Inventory Management value.

• Activation Service Action Structure to realize technical actions in Design Studio for ASAP projects as service actions (CSDLs).

• None if the action will not realize as a Design Studio entity. If you select this option, the Realization Design Pattern field is not available.

• Other Action if the action will not realize as one of the available Design Studio entities but if you want to select a custom design pattern from the Realization Design Pattern field to generate code. See Design Studio Developer's Guide for more information about creating custom design patterns.

• Ruleset Structure to realize service actions in Design Studio for Inventory project as rulesets.

• Scan Action Structure to realize technical actions in Design Studio for Network Integrity projects as scan actions.

• Save the Action editor.

• Change the action using an option that you select from the context menu.

• Manually synchronize or realize a direct child of the action.

See "Synchronizing Conceptual Model Entities with Application Entities" for more information.

Binding a data element indicates that the data element defined in the conceptual model entity is the source for the target data element defined in the action family.

Right-click a data element in the Action Family area and select Add Custom Binding to define a relative path to a data element outside of the conceptual model subject.

Design Studio displays a marker next to data elements defined with custom bindings to enable you to identify those bindings quickly. All custom bindings are displayed on the Custom Bindings tab.

You may need to define the context more broadly if the information required by the set of technical actions must be sourced from multiple areas of a conceptual model tree.

• Select Include All Actions to include all technical actions defined for the subject in the action family.

• Select Select Specific Actions to limit the scope of the action parameter binding to a subset of actions defined for the subject. The actions appear in the Action field. You can add to or remove any technical actions defined for the subject.

  For example, you might have technical actions to create, modify, and delete entries in the network address template. You can create a single action parameter binding for all of these technical actions, or you can limit the scope if you require alternate bindings for specific scenarios.

  By default, all actions associated with the subject are included in the action parameter binding.

Service order management and technical order management layers support actions. Commercial order management layers do not support actions.

Define the naming convention of the functional area actions by specifying a value in the Action Prefix field. For example, if configuring a service order management functional area, you might define this value as service_action.

• Mandatory: Select to indicate that the conceptual model entity requires an association with the type of action defined by the functional area. When this option is selected for an entity in the Supported Entity Types table, Design Studio automatically creates an action entity and associates the action entity with any new entities that you create.

• Multi Instance: Select to indicate that multiple actions can be associated with the conceptual model entity. Customer facing services can have only one associated service action. Resources, however, can be associated with multiple technical actions.

• Extend Subject by Default: If selected, indicates that the data elements defined on the conceptual model entity are inherited by associated actions.

Select an action code and click Open to open the code in the Action Code editor.

Each functional area can be realized by a different OSM order, each with a unique orchestration configuration.

• Save of the Functional Area entity.

• Change the Functional Area entity using an option that you select from the context menu.

• Manually synchronize or realize a direct child of the Functional Area entity.

See "Synchronizing Conceptual Model Entities with Application Entities" for more information.

Provider functions are processing components that perform a defined set of tasks based on its role in a solution. Design Studio includes the configuration for some provider functions, such as Calculate Service Order, Design and Assign, Calculate Technical Order, and Activation.

Do one of the following:

• Click Open to open the selected provider function in the Provider Function editor.

• Click Add to create a new provider function to associate with the functional area.

• Click Remove to delete the selected provider function from the list.

• Click Select to associate an existing provider function with the functional area.

For example, the Calculate Service Order provider function only recognizes Product entities as input.

• Entity Type displays the conceptual model entity type that is selected in the Input Types table. Click the menu to change the value to a different entity type.

• Action Type displays the type of action associated with the conceptual model entity selected in the Input Types table. The provider function uses the actions associated with the entity type as input.

  The value that initially appears in this field is determined by the configuration defined in the functional area.

  Click Select to select a different functional area.

For example, the Calculate Service Order provider function only recognizes products as input, and generates only the actions associated with Customer Facing Service and resources.

• Entity Type displays the conceptual model entity type that is selected in the Output Types table. Click the menu to change the value to a different entity type.

• Action Type displays the type of action associated with the conceptual model entity selected in the Output Types table. The provider function uses the actions associated with the entity type as output.

  The value that initially appears in this field is determined by the configuration defined in the functional area.

  Click Select to select a different functional area.

For example, the Calculate Service Order provider function recognizes products as input, and generates actions associated with customer facing services as output. The relationship between a product and a CFS entity is derivational, meaning that the CFS entity has a primary relationship to one product. Typically, Calculate Service Order generates a CFS entity (it can also generate resources, but that scenario is less common). Therefore, the default relationship is defined as Primary. See Design Studio Concepts for more information.

• Click Open to open the entity in Relationship Type editor.

• Click Add to create a new entity and to include the new entity as an additional relationship type.

• Click Remove to remove the relationship type from the provider function.

• Click Select to add an existing relationship to the provider function.

• None if the Provider Function entity does not realize as an Order Transformation Manager entity.

• Transformation Manager to specify that the Provider Function entity realizes as a Transformation Manager entity.

Click Open to open the selected application entity editor.

Tokens are placeholders that represent information to be collected by the Design Pattern wizard from a user applying a design pattern. Tokens ensure that the resources a design pattern copies to a workspace are based on information supplied by the user who applies the design pattern. See the Design Studio Developer's Guide for more information.

Tokens are placeholders that represent information to be collected by the Design Pattern wizard from a user applying a design pattern. Tokens ensure that the resources a design pattern copies to a workspace are based on information supplied by the user who applies the design pattern. See the Design Studio Developer's Guide for more information.

Tokens are placeholders that represent information to be collected by the Design Pattern wizard from a user applying a design pattern. Tokens ensure that the resources a design pattern copies to a workspace are based on information supplied by the user who applies the design pattern. See the Design Studio Developer's Guide for more information.

The Value field displays the value of the selected token supplied by the user who applied the design pattern. Click Select to change the value. Click Value to open the token value in the appropriate Design Studio editor.