How to Read a Recipe

SMI Tutorial > SMI-S 1.1.0 Overview > How to Read SMI-S 1.1.0 > How to Read a Recipe

How to Read a Recipe

SMI-S History | SMI-S 1.1.0 Requirements | How to Read SMI-S 1.1.0

How to Read Profiles | How to Read Recipes

A Profile, Subprofile or Package can define Recipes that a Client may use to perform a particular management task on the elements being managed. Using comments and PERL-like expressions, a Recipe describes the specific WBEM operations that must be performed, the order in which they must be performed and the argument values to be used for each WBEM operation.

A Recipe typically has the following components:

Description - describes the purpose of the Recipe
Pre-Existing Conditions and Assumptions - lists the operations that have already been performed before the Recipe is executed
Steps - explains each step of the Recipe

The following is an example Recipe from the Server Profile. This Recipe verifies that the version of the Subprofiles match that of a particular Profile. The Recipe can be interpreted as follows:

Step 1 performs the WBEM operation GetInstance to an instance of CIM_RegisteredProfile and then extracts the Profile version number from the instance.
Step 2 retrieves all instances the Subprofiles of the Profile using the Associators WBEM operation and then extracts the Subprofile version number from returned instances
Step 3 compares each Subprofile version number to the Profile version number

// DESCRIPTION
// A management application wishes to determine the optional subprofiles
// supported by a SNIA Profile.
//
// PRE-EXISTING CONDITIONS AND ASSUMPTION
// 1.Assume the client has already discovered the CIM Server that
//     supports the SNIA profile
// 2.Assume the client already has a $ObjectManager-> reference for
//     the CIMOM on the WBEM Server.
// 3.Assume the client already has a $RegisteredProfile-> reference
//     for the profile in question.

// Step 1: Check the version of the supported profile. Based on the
//     RegisteredVersion property, the client should know what functions
//     are REQUIRED as part of the profile definition.
$Profile = GetInstance($RegisteredProfile->)
#ProfileVersion = $Profile.RegisteredVersion

// Step 2: For each Profile, traverse the SubProfileRequiresProfile
//     association to determine what optional subprofiles are also
//     supported. If the subprofile (e.g., CopyServices subprofile)
//     exists for a profile, this means that the copy services are
//     supported. The Copy Services also has a Version
//     (RegisteredSubProfile.RegisteredVersion). The RegisteredVersion
//     of the subprofile MUST match the RegisteredVersion of the profile.
//     The RegisteredVersion implies a set of functional capabilities
//     that are defined for that version of the subprofile.
$Subprofiles[ ] = Associators (
        $RegisteredProfile->,
        “CIM_SubProfileRequiresProfile”,
        “CIM_RegisteredProfile”,
        NULL, NULL, false, false, NULL)

// Step 3: Verify that each Subprofile has the same version as the
//     Profile
for #i in $Subprofiles[ ] {
       #SubprofileVersion = $Subprofile[#i].RegisteredVersion
       if (!compare(#SubprofileVersion, #ProfileVersion)) {
              Error(“Subprofile version mismatch with Profile version”)
       }
}