Filtering out service catalog items during deployment

Service Catalogs comprise of atomic and composite items. During modeling the Service Designer builds these items with the appropriate dialogs and entry points for the state machines.

During deployment of a service the end user might want only specific catalog items from a bundle based on their selections. The Service designer can factor the dynamic nature of the selection process into the model.

The link below has more details on the above use case along with a workaround
Service Item Selection

Allow for a call into Automate Engine to decide if a service item should be included during deployment. When we encounter a service item during provisioning before we create a task for it, we call Automate to run a method defined in /Service/Provisioning/Profile/<> instance to check if the service item should be included.

The Automate Method gets passed in

  • The Service Item $evm.root[ā€˜service_templateā€™]
  • The Provision Task $evm.root[ā€˜service_template_provision_taskā€™]
  • The Parent Service Object $evm.root[ā€˜serviceā€™]

If it wants the Service item to be included the method should set the include_service attribute in the root object as true else it should set it to false.
$evm.root[ā€˜include_serviceā€™] = true
If it wants the service to be excluded it should set it to false
$evm.root[ā€˜include_serviceā€™] = false

1 Like

Wouldnā€™t it be easier to filter out the items from the children list ? I mean, simply drop the item from the list.
It could be a state in /Service/Provisioning/StateMachines/CatalogBundleInitialization.

BTW, from my point of view, all services in the catalog should be bundles of items. That would make the whole service experience more consistent : whatever the number of items, you create a bundle.

When a service provision is started, it creates the Service Request and tasks for all the Service Items. After this is done for each of the service we call the appropriate state machines. Thats where the CatalogBundleInitialization and other state machines are called. This leads to creation of unnecessary tasks and skipping these tasks either from the state machine or using an assertion (the workaround used in the cloudforms link).

The approach we are proposing runs the Automate Method to do the filtering before the tasks are created so it saves the overhead of creating them and then turn around and filtering them out.

Thanks for the explanation. It is not that obvious when you read the AE code. Thereā€™s a lot of hidden callsā€¦

A sample method is provided in
/ManageIQ/Service /Provisioning/ServiceFilter/FilterByDialogParameters

This method is referenced from

During the service workflow when we are creating the tasks for each of the services we call