IT Operations Management (ITOM)
cancel
Showing results for 
Search instead for 
Did you mean: 

Demystifying Data Center Automation (DCA) Suite Operations Portal’s offerings-Series#4.1: New Design

Demystifying Data Center Automation (DCA) Suite Operations Portal’s offerings-Series#4.1: New Design

lazarmi

Hello audience,

It is great to have you back reading this series. Hopefully you enjoyed my other blogs in the series ( #1 #2 #3) as well.

During this series, we started from scratch with the design and the implementation of a new use case or service a user could select from the Hewlett Packard Enterprise Data Center Automation Operations Portal.

Whilst designing a new use case, a few things should be taken into account:

  • What the use case should are we looking to accomplish end-to-end?
  • Which are the inputs for Operations Orchestration (OO) flow/s?
  • Which options will be available for the user requesting/ordering this service?
  • Which data will be stored for future reference or usage?
  • Are there any special security and access privileges requirements?

 With these in mind we can start our journey!

 Today’s use case is a simple one, with an educational purpose of highlighting each step/concept. Of course, the complexity can be gradually increased. Its name is “Run Communication Test on an already managed server”.

 Let's assume that your playground has been already set and that all Content Packs(CPs) available within the downloaded archive, “DCA_VA_1601_1_OOTB.zip”, were already imported into OO Studio (if not please have a look over Series #2). The next step will be to create a new project in the OO Studio, let’s call it “DCADemo”.

Once the project has been created, expand it, right click on the “Library” folder and click “New” > “Folder” > “Exercises”. This new path created “/Library/Exercises/<name of the flow/s>” will help us differentiate our flows by the other flows in OO Central.

On the newly created folder, create a new flow called “RUN_COMM_TEST_MANAGED”.

Fig.1 OO Flow PropertiesFig.1 OO Flow Properties

Because OO reads and populates a series of properties from various Cloud Service Automation (CSA) tokens*, the following properties should be specified on the newly created flow for the CSA’s Service Design to populate them.

 

 

 

 

 

 

Tip!Fig.2 Copy&PasteFig.2 Copy&Paste

 

Copy and paste all values from an already existing flow into “Data Center Automation Appliance” Content pack:

 

 

 

 

 

 

*more details about these tokens can be found within “DCA_VA_2016.01_Installation_and_AdministrationGuide.pdf”

In series #3 we talked about three mandatory operations for each and every newly created flow (see the 3 highlighted ones):

Fig.3  Mandatory OperationsFig.3 Mandatory Operations

  • 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)
  • Because OO 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)
  • 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, …); Pay attention to the filters!

 Copy these 3 operations from an existing flow or add them from the correspondent Content pack (CSA-INTEGRATIONS [4.50.0000]) along with a “Notify Error” operation and the “Error” exit status.

Fig.4 Add the mandatory operationsFig.4 Add the mandatory operations

 

Now, click on the “Search” option and type “Run Communication Test”.

 Drag both operations into the canvas and make the wiring too:

Fig.5 Add Run Comm Test related operationsFig.5 Add Run Comm Test related operations

 

Wonder why both are needed? Double click on each of them and check out the “Description”

  1. Run Communication Test: Run communication test on the given SA server or device group. This operation is supported from SA version 9.1 (sas91).
  2. Run Communication Test Job Result: Retrieves the output of a run communication test job.

 

The next step is to see which are all the required “Inputs” for all these operations. This allows you to see which of them can be queried from the CSA “backend” and which ones can be filled out by the final user. You can also see in which way they can be queried: manually by specifying a string or an integer or in a dynamically way by executing a JSP script to load a list of values the final user to choose from.

By double clicking on each operation we can summarize all the required inputs:

  • Get User Identifier
    • csaUser (Default value: Gets from CSA_OO_USER system property which is set to "ooInboundUser")
  • Get Artifact Properties
    • artifactId
    • userIdentifier
    • propertyNames
  • Get Resourcer Provider Details
    • providerID
    • userIdentifier
  • Run Communication Test
    • coreHost
    • coreUsername
    • corePassword
      • attachableName - The names of either the servers, or the device groups, separated by 'separator'.
      • attachableID - The ids of either the servers, or the device groups, separated by 'separator'. If provided, the 'attachableName' will be ignored.
    • attachableType
  • Run Communication Test Job Result
    • coreHost
    • corePort
    • coreProtocol
    • coreUsername
    • corePassword
    • jobID

Without the “outputs” or the results of each operation we cannot solve the whole puzzle.

So, switching to the results of each operation, we can see that:

  • Get User Identifier provides userIdentifier for Get Artifact Properties
  • Get Artifact Properties provides the inputs for Run Communication Test and Run Communication Test Job Result (will get back to this topic soon)
  • Fig.6 ResultsFig.6 ResultsGet Resourcer Provider Details provides the “credentials” for Run Communication Test and Run Communication Test Job Result actions (coreHost; corePort; coreProtocol; coreUsername; corePassword) and no need to hardcode them into system properties or other variables .
  • Run Communication Test provides the returnResult - The id of the job created to Run Communication Test Job Result
  • Finally, Run Communication Test Job Result, provides various details about the Communication Job execution:
    • serverName - The names of the servers against which the run communication test job was ran.
    • serverID - The IDs of the servers against which the run communication test job was ran.
    • agentReachable - The flags indicating, for each server, if the SA agent is reachable.
    • securityOK - The flags indicating if the encryption and security between each server and the SA core are OK.
    • commandEngine - The flags indicating, for each server, if it can retrieve commands to be executed from the SA core.
    • dataAccessEngine - The flags indicating, for each server, if it can retrieve its stored device information from the SA core.
    • softwareRepository - The flags indicating, for each server, if it can retrieve software and patches from the SA core.
    • machineID - The flags indicating, for each server, if its machine ID matches the one stored in the SA core.
    • reachabilityTime - The reachability time, for each server.
    • lifecycle - The lifecycle of each server.
    • osVersion - The OS version of each server.

 Since the job’s execution provides the above details, it would be nice if they were displayed on CSA as well. To accomplish this we will need a “/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Update Service Component Property” operation to accomplish it.

At this moment, we will need to add one operation just to be able to continue with the design. Later you will need to return  here to add as many as needed in order to reflect all these details into CSA.

If no other action needs to be taken, somehow we have to inform the CSA itself that the flow has completed and we can do it with an operation like: “/CSA-INTEGRATIONS [4.50.0000]/Library/Integrations/Hewlett-Packard/Cloud Service Automation/Update Process Instance State”. We will also make use of the already discussed token: “CSA_PROCESS_ID”, automatically filled out at runtime.

 Finally,  we also have to announce to the OO that all actions are successfully finished by moving the flow into “Resolved: success” state.

All the above three actions can be summarized in the following screenshot:
Fig.7 First SketchFig.7 First Sketch

 Fig.8 Starting StepFig.8 Starting Step

 

One final warning: no starting point has been set:

 

 

 

 

 

 

 

 

 

And here is the first possible final version: (don’t worry, will revert for the final tunes soon)

Fig.9 First possible final versionFig.9 First possible final version

 This conclusion is based on the already summarized inputs that most of the inputs are “resolved” by straight querying into CSA--but we still need a way to provide them for the following:

  • attachableName - The names of either the servers, or the device groups, separated by 'separator'.
  • attachableID - The ids of either the servers, or the device groups, separated by 'separator'. If provided, the 'attachableName' will be ignored.
  • attachableType -  The type of the attachable items. Can be one of the following values: SERVER or DEVICE_GROUP.

We can see a new input which is not among our summarized inputs list: “attachableID”. From its description we can observe that we can use either “attachableName” or “attachableID” and sometimes we can find better benefits in using one or the other(one example is that the name can repeat, “localhost” for instance if the hostname hasn’t been explicitly set but the ID will be unique all the times).

Here we move to next step in our journey: CSA’s Design and how we will pass those values from the user’s interface in a manual way. Start by writing down the value at each execution; why not begin by hardcoding them and using same value all the time without mandating user interaction. Or, in a dynamic way where the user can choose from a list of values--or even offer a mixture of them.

 For now we will choose a dynamically-populated list at the runtime for “attachableName” or “attachableID” (based on the already available JSP scripts*) and a manually or hardcoded introduced value for “attachableType”.

 *Note

[root@dca201601 /]# cd /usr/local/hp/csa/jboss-as/standalone/deployments/csa.war/propertysources/ && ls

Properties.jsp                 itoc-policies.jsp                    sa-deviceGroup-staticOnly.jsp  sa-realms.jsp            sa-unprovisioned-physical-servers.jsp

hp-cda-dynamic-properties.jsp  sa-agentOSFamilies.jsp               sa-hypervisors.jsp             sa-remediationTypes.jsp  sa-virtualOSBPs.jsp

itoc-businessServices.jsp      sa-commons.jsp                       sa-managed-servers.jsp         sa-serverScripts.jsp     sample-client-token.jsp

itoc-commons.jsp               sa-customers.jsp                     sa-osbps.jsp                   sa-softwarePackages.jsp  sample.jsp

itoc-maintenanceWindows.jsp    sa-deviceGroup-staticAndDynamic.jsp  sa-patchPolicies.jsp           sa-softwarePolicies.jsp  topologicalDynamicProperty.jsp

 In order to start the CSA design, first of all we have to login into the Administration Console/IT Operator Portal*. Then switch to Designs > Sequenced > Designer > scroll to the bottom > Create. Choose a new name for it “Run Communication Test on an already Managed Server”.  If needed, add a description “Run a Communication Test on an already Managed Server by manually choosing the target server from a dynamically populated list of servers”, add a version and an image and finally hit “Create”.

*edit the URL to reflect the correct DCA’s IP address

 We’ve created the Service Design: 

Fig.10 Service DesignFig.10 Service Design

 

In the “Designer” tab, we will add all the components, properties(*) and link with the already created OO flow. The “Subscriber Options” will  create all the options available for the final user and link them with the properties(*) from the previous step.

 

Fig.11 Create the Root ComponentFig.11 Create the Root Component

So let’s start with the “Designer” tab and create the root component which will be the basis for the whole design:

 

 

 

 

 

 

 

 

 

And place it onto the canvas:          

 Fig.12 Place the Root Component into the CanvasFig.12 Place the Root Component into the Canvas

 

Scroll over the already placed component and “Create New Child Service Component” Fig.13 Create New Child Service ComponentFig.13 Create New Child Service Component

 

This action will place a new component (follow the above instructions in order to add an “Infrastructure Service” component) which will do the actual Communication Test

Fig.14 Add a child componentFig.14 Add a child component

 

Here is where we link the Design with the OO flow and add the Properties too.  Only the second part-adding the needed Properties (later on will gonna add the Subscriber Options as well)- can be accomplished now.

The OO flow cannot be linked here because we did not create a content pack (CP) with the flow from OO Studio. We did not deploy the CP into OO Central and we did not synchronize CSA with the OO Central in order to see the “Process Definition”  OO flow in CSA.

So let’s set the property's OO flow to query from CSA in order to fill the mandatory inputs (as previously said, most of the inputs would be automatically “resolved” by a straight query into CSA and those inputs are the credentials, IPs, ports … inputs available by reading the Provider’s details, in this case).

Fig.15 Provider's DetailsFig.15 Provider's Details

 And again, we need to focus on those 2-3 inputs. To accomplish this, the final user has to provide:

  • attachableName - The names of either the servers, or the device groups, separated by 'separator'.
  • attachableID - The ids of either the servers, or the device groups, separated by 'separator'. If provided, the 'attachableName' will be ignored.
  • attachableType - The type of the attachable items. Can be one of the following values: SERVER or DEVICE_GROUP.

Looking over the “sa-managed-servers.jsp”, this line will tell you what that JSP will output:

“servers.put("description", server.getServerId()+"#"+server.getServerName()+"#"+platformIdAndName);”

Fig.16 Properties & ValuesFig.16 Properties & Values

 As we can see it outputs the Server’s ID, the Server’s Name, the SA Platform’s ID, and the SA Platform’s Name so either Server’s ID or Server’s Name can be used:

 

 

 

 

 

 

 

 

 

 

  Make sure you use the Server’s ID (for uniqueness reasons) and for “attachableType” will hard code with the value “SERVER” for simplicity.

 Click on “Infrastructure Service” component and from the right side options choose “Properties”.

Define the following two properties: “attachableID” as “List” Fig.17 attachableIDFig.17 attachableID

 

 

 

 

 

 

 

 

 

 and “attachableType” as “String”

Fig.18 attachableTypeFig.18 attachableType

 

 

 

 

 

 

 

 

 

 

 

Here how it should look:

Fig.19 PropertiesFig.19 Properties

 

Next step will be to set the subscriber’s options and for this, switch to “Subscriber Options” tab > “Create Option Set” > Edit the details > add 2 properties to be linked with the already created 2 properties within “Designer” tab.

 

Here is how to edit the details and create a new property:

Fig.20 Subscriber Options PropertiesFig.20 Subscriber Options Properties

 Here is how to fill up all the mandatory fields, add the dynamic JSP query – tFig.21 Dynamic QueryFig.21 Dynamic Queryhe script we’ve talked about “sa-managed-servers.jsp” – and how to bind to the already created property which will be stored by CSA and queried by the OO flow:

 

 

 

 

 

 

 

 

Fig.22 Property BindingFig.22 Property Binding

Perform the same procedure for the other property:

Fig.23 Property DetailsFig.23 Property Details

 

Fig.24 Property BindingFig.24 Property Binding

 

Now we have to “Save” the changes in order for the Options Set to be reviewed or for the dynamic query to be tested:

Fig.25 Options SetFig.25 Options Set

 

 If the properties and the options set were defined, normally we have to link the Service Design to the OO flow. Since we did not synchronize the CSA with the OO Central, thus the OO flow not available for linkage, we can create a “Resource Offering” and link this Service Design to a Resource Offering, resource which can be edited later on, after the sync process will occur. (you’ll find it better to add the OO flow into a Resource Offering rather than directly into the Service Design - since the last one will not allow you to edit it after publishing it and once published you have to create a new version all the times - Resource Offering which can be independently edited and all the Service Designs will make use of it without any changes).

Fig.26 Create a new Resource OfferingFig.26 Create a new Resource Offering

 Again, from the Administration Console > Designs > Sequenced > Resource Offering > HPE Server Automation > Create New Offering > “Run Comm Test”

 

 

 

 

 

 

 

 

 

 Click on the newly created Resource Offering “Run Comm Test”, switch to “Providers” and associate it with the “HPSA” provider.

Nothing else should be done on this Resource Offering at the moment since will revert here to add the Process Definition aka the OO flow.

Go backwards one step and click on “Designer” > click again on “1.0.0” version for our Service Design “Run Communication Test on an already Managed Server” > switch to “Designer” > click on “Infrastructure Service” component > from right-side, within “Resource Bindings” tab click on “Create New Resource Binding” > Monitoring (or a different category can be chosen)> and choose “Run Comm Test”, our already defined Resource Offering.

Fig.27 Create a new Resource BindingFig.27 Create a new Resource Binding

 

What remained? To publish our Service Design, to create a new Offering, add our Service Design into that Offering and publish the Offering into a catalog.

For this, switch to “Overview” and “Publish” the Service Design.

 Now, from the Administration Console > Offerings > Create > from the drop down list choose our Service Design > choose a Display Name “Run a Communication Test job on an already Managed Server” > eventually add a Description > click on “Create”.Fig.28 Create a new OfferingFig.28 Create a new Offering

 

The last step is to publish this new already created offering into a catalog so it is available for the final user in the “Operations Portal”:

Fig.29 Publish the OfferingFig.29 Publish the Offering

 

And here we go! The Offering is available into the Operations Portal and ready to be checked out

Fig. 30 Operations PortalFig. 30 Operations Portal

 

Since we have finished with the CSA “design”, all properties, options have been set, the offering is available in the Operations Portal, we have to revert to the OO flow for some refinements. These refinements include: set the list of properties to be queried from CSA (“attachableID” and “attachableType”), pass the info queried to flow variables to be sure that each action will get the right inputs and the values will not be lost, update CSA’s subscription with the relevant info and finally, to create the OO CP, deploy it into OO Central and run the Process Definition Tool in order to synchronize CSA with all the available OO Flows.

After all of these were made, will revert to the already created and bound Resource Offering, to add our OO Flow/Process Definition into!

I hope this guide helps you with the design process between Operations Orchestration's flows and CSA’s Service Design creation. There are opportunities to have refinements and adjustments in order to accomplish the initial desired idea!

 Because of the length of this article the continuation is posted  via this link

 Here some quick links for the other series:

 Notes:

  • The OO Content Pack, OO Project and the CSA’s Offering (which contains the Service Design, Resource Offering as well) will be attached to the following blog post

 

 

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
About the Author

lazarmi

Comments
HPE Expert

Hello Mihai, great blog to get started on DCA. A video with all these steps will be really helpful if possible. Please keep posting these blogs, very helpful. 👍

Occasional Contributor

It's really good to see a common look and feel - the new design works well

Member

Wow this is very informative, thanks!

Occasional Contributor

We are new to using HPE in the DCA area - looking forward to it. Thank you for the article. 

Regular Collector

While CSA is an interesting canvas to work on, I'd be very interested to see this extended to something like a SM call out or an OMi auto-triggered action

//Add this to "OnDomLoad" event