IT Operations Management (ITOM)

Demystifying Data Center Automation (DCA) Suite Operations Portal’s offerings-Series#3: InstallAgent

Demystifying Data Center Automation (DCA) Suite Operations Portal’s offerings-Series#3: InstallAgent


Hello again,

It is great to have you back reading this series which will demystify the out-of-the-box offering “Install Server Automation (SA) Agent”.

If you have missed either blog, you can catch up here:

When launched from the Data Center Automation Operations Portal, the “Install Server Automation (SA) Agent” offering provides several options for the user to be filled: 

Fig.1 Install Server Automation (SA) Agent offeringFig.1 Install Server Automation (SA) Agent offering



Are you wondering how those options are created? Linked with other ones and finally how the Operations Orchestration (OO) makes use of them?

This is what this series covers till the end of, so let’s get a closer look.



Fig.2 IT Operator Portal Service DesignFig.2 IT Operator Portal Service Design

At the base of each and every offering you find an IT Operator Portal Service Design*, which is the recipe for automating the cloud. It can be comprised of other reusable service components and can provide options that consumers can select when ordering a service too.

*for more info please check Cloud Service Automation (CSA) documentation available here.










The next step is to bind each component to a Resource Offering which will define the overall design’s lifecycle (each phase can contain one or more Process Definitions - the OO flows) and constrains the provider selection as well.

Fig.3 Binding each component to a Resource OfferingFig.3 Binding each component to a Resource Offering



Fig.4 PropertiesFig.4 Properties

Once the binding is done, the next step is to define the Properties














Fig.5 Service Design's PropertiesFig.5 Service Design's Properties

Q: Which Properties are present and what’s their meaning? 

A: The obvious answer is the Service Design’s Properties (list of name & value pairs) which will be stored into the Database. They can be used for multiple purposes and they can also be used as input for the OO flow/s.






But still, where are the available options for the user and how those options are used by Operations Orchestration?

Fig.6 Subscriber OptionsFig.6 Subscriber Options

Half of the answer is the Subscriber Options tab which allow to expose service design options in the Offerings, statically, or into a dynamically way, which allows to choose the options from various sources and the binding between these Options and the already discussed Properties.

In other words, the values entered by the user will end up stored into the Database and if needed, are available for the OO flow/s as inputs.








The other half of the answer is the OO flow itself,

Fig.7 OO FlowFig.7 OO Flow

Which will be thoroughly explained:

  • The central piece of the whole puzzle is the following operation: Get Properties to Install (/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Get Artifact Properties)
  • Fig.8 Get User IdentifierFig.8 Get User IdentifierBecause Operations Orchestration needs IT Operator Portal (CSA) ‘s credentials, Get User Identifier (/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Get User Identifier) operation is a prerequisite for the above one(Get Properties to Install)







  • Fig.9 Get Properties to InstallFig.9 Get Properties to InstallBack to the central piece, Get Properties to Install, we can observe that here we’re querying all the Properties set on the Service Design, to be fed as inputs to the next operations


  • As inputs, for propertyNames all the Properties “to be queried” are specified/hardcoded (performance reason); if none of the properties are specifically queried ALL available properties will be queried
  • As results, all the “raw” queried values should be filtered in order to keep only the value - not the name of the properties and the delimiters
  • It’s mandatory to assign those values to new OO flow variables to be sure that the subsequent operations can make use of them



  • Fig.10 Get Resource Provider DetailsFig.10 Get Resource Provider DetailsThe next piece is Get Resource Provider Details (/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Get Resource Provider Access Details) and as the name says, all the providers involved into this equation are queried (URLs, credentials, …); Make sure you pay attention to the filters!






    • Fig.11 Agent InstallerFig.11 Agent InstallerAfter we’ve met all the requirements we’re at the piece which actually do the job: Agent Installer (/Data Center Automation Appliance [1.1.1]/Library/Data Center Automation Appliance/Server Management/Subflows/Agent Installer) which is a custom Subflow which in turn uses Install HP Server Automation Agent operation (/SA [1.2.0]/Library/Integrations/Hewlett-Packard/Server Automation/Agent/Install HP SA Agent)




  • Fig.12 Update ServerID and Update Job IDFig.12 Update ServerID and Update Job IDFinally, in case the previous operation succeeded, we’re updating our Operations Portal Subscription’s Service properties via Update ServerID and Update Job ID (/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Update Service Component Property) and the Subscription itself with the OO flow completion via Notify Flow Completion (/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Update Process Instance State)



Supposing that the interest in this topic is still high, stay tuned for the next series: “Starting the design for a brand new Use Case …



Here some quick links for the other series:




Mihai Lazar
Automate & Orchestrate Solution Architect

*If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.
  • infrastructure management
0 Kudos
About the Author