2 of 2 people found this helpful
BMC CLM does not recommend to have multiple providers for custom hostname.
There is also a possibility of provider disambiguation where during provisioning flow if the hostname operation is called, in a multiple provider case, the flow will be getting 2 providers which provide hostname advisor operation and the request can land in anyone of it, though there is something called as disambiguation rule which you can put to handle it but ideally the AO workflow that you write should have different paths based on certain criteria instead of implementing multiple custom providers.
One of the ways which you may think of doing it is -
- you can register the custom hostname advisor.
- Grab the XML request which goes to your AO workflow
- De-register the custom hostname provider
- Work on the XML if you want to test out the hostname patterns and then fix it
- RE-register the provider if you want to go ahead with it.
This way you will not break the existing flow till the time you have finalized something on the custom hostname advisor part.
2 of 2 people found this helpful
You could have one provider and simply create a 'Naming Standard' Tag Group. In your main custom hostname adviser workflow simply obtain this tag value from the inputxml and then call the appropriate custom hostname workflow. You could also have a default path (i.e. no tag value found) to avoid the need to set a tag on every service/blueprint or affect the existing production CHA workflow.
Hope this helps
I will probably take the former course -- it seems simpler and more straightforward, if less versatile -- but I must ask, how would I create a "Naming Standard" tag group?
Re-reading Devendras suggestion I think we are suggesting the same thing - his first option - having a single provider but having the workflow go down different paths. I don't think the second option (de-registering and registering the provider) will work if you have a number of concurrent CLM requests requiring different standards. The suggestion of using Tags is a simply way of enable your CHA workflow to go down different routes.
To configure tags performing the following: Within CLM edit an existing blueprint or create a new one. Open the service properties (or one of the many places you can add a tag) click the '+' to add a tag. Scroll to the bottom and you can add a new tag group [i.e Naming Standard] and tag [i.e. <Standard 1>], [Standard 2] etc.
You will then be able to save these tags directly on any blueprints you create.
When you trigger a CLM provisioning job. you will find the Tag details in the XML it sends to the Custom Hostname Advisor. Your workflow would have logic such as:
1) Parse XML for 'Naming Standard' Tag Group and Get 'Tag' name.
2) If 'Tag' = null go down default route i.e. call production naming standard workflow.
3) If Tag = <standard 1> call AO workflow x, <standard 2> workflow y etc.
This will allow you to develop different standards and simply drop them into the main CHA workflow when ready.
1 of 1 people found this helpful
The reason to recommend de-registration of provider is because it's a pre-production environment where things should continue to work smoothly while he develops the workflow and test out certain things. He has not finalized his approach yet as per his original comment.
Register the provider and get the XML to develop the workflow offline. De-registration will ensure that other users can continue to use the environment and your workflow is not breaking their stuff.
Once you have finalized all possible paths in the workflow and have tested it out you can then hook it back.
I hope this clarifies my point.