Catalog Item Policy Tags from CatalogItemInitialization


#1

Hi,

I have a catalog item that works well - when the provisioning process reaches the CatalogItemInitialization method I can inspect dialog_options_hash to see the selections the user has made and control the request appropriately.

I want to extend the functionality by associating tags with the Catalog Item using Policy. However, I can’t see how to access those tags within CatalogItemInitialization. Can anyone supply a snippet of code that demonstrates how I can access the Catalog Item tags within CatalogItemInitialization?

Thanks in advance for any help,
David

PS - I’m using CloudForms 4.1


#2

Hi David

If you create a text box element in your service dialog, and name it as tag_0_category_name (for example tag_0_department), then any value input by your user into that text box will be added to the service as a tag. If you scroll down to “Service Dialog Element Naming Convention” here: https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-4-2-and-manage/content/catalogitembundleinitialization/chapter.html, there’s a sub-section “Single tag” that describes this in more detail.

You shouldn’t have to edit CatalogItemInitialization at all.

Hope this helps,
pemcg


#3

Hi,

Thanks for the fast response, but I guess I didn’t word my question well! :slight_smile:

I have had a lot of success creating elements in dialogs for users to specify. And then I have successfully edited CatalogItemInitialization to process the user input and drive the provisioning process. So far so good. :slight_smile:

But now I want to have data available within CatalogItemInitialization that the user does not have access to except by the Catalog Item they have selected. This data will always be the same for that Catalog Item, but might be different for another Catalog Item. The way to do this seems to be to set tags via policy within Services\Catalog Items\Plocy Button\Edit tags. This works perfectly because when the VM provisioning is complete the object within CloudForms has the appropriate tags set. What I can’t see how to do is to use those tags within CatalogItemInitialization.

For a real world example - I have a field in my dialog that asks the user if an inventory item should be created for the newly provisioned VM or not. That works by a tag control element that sets tag_0_inv. The problem is that the end user does not know the answer to the question - it is something determined by the catalog item they have selected and they should never have to think about it. I can set the tag by Catalog Item , but somewhere in the provisioning process I need to make a decision based on that tag as to if the inventory item needs to be created or not and to initiate that process if it is.

That’s just one example though - there are many more, the first of which I hot in the CatalogItemInitialization method.

Thanks again,
David


#4

Aah, I see now :slight_smile: I think you want to test the task.source object for tags.

To test I just tagged a service catalog item with Department/Engineering, and added this code to CatalogItemInitialization:

  @task = $evm.root['service_template_provision_task']
  # new lines...
  if @task.source.tagged_with?("department", "engineering")
    $evm.log(:info, "Parent service is tagged with department/engineering")
  end
  # end of new lines

When I order a service from this catalog item I see in the log:

<AEMethod catalogiteminitialization> Parent service is tagged with department/engineering

Hope this helps,
pemcg


#5

Hi,

Sorry for the delay replying. Your example snippet is exactly what I required - it works beautifully!

Looking through your excellent how-to guide I found a section on tags and from that deduced that I can do this to get the tag value:

    inv = @task.source.tags(:inv)

Before that I wanted to test if the tag is set and tried this:

  if @task.source.tags(:inv).empty?
    inv = default_inv
  else
    inv = @task.source.tags(:inv)
  end

Do you think that ‘empty?’ test is correct, or is there a better way of doing it?

Thanks again,
David