9. Mock support¶

Experimental: New in pywbem 0.12.0 as experimental.

9.1. Overview¶

The pywbem package contains the pywbem_mock subpackage which provides mock support that enables usage of the pywbem library without a WBEM server. This subpackage is used for testing the pywbem library itself and can be used for the development and testing of Python programs that use the pywbem library.

The pywbem mock support contains the pywbem_mock.FakedWBEMConnection class that establishes a faked connection. That class is a subclass of pywbem.WBEMConnection and replaces its internal methods that use HTTP/HTTPS to communicate with a WBEM server with methods that instead operate on a local in-memory repository of CIM objects (the mock repository).

As a result, the operation methods of FakedWBEMConnection are those inherited from WBEMConnection, so they have the exact same input parameters, output parameters, return values, and even most of the raised exceptions, as when being invoked on a WBEMConnection object against a WBEM server.

Each FakedWBEMConnection object has its own mock repository. The mock repository contains the same kinds of CIM objects a WBEM server repository contains: CIM classes, CIM instances, and CIM qualifier types (declarations), all contained in CIM namespaces.

Because FakedWBEMConnection operates only on the mock repository, the class does not have any connection- or security-related constructor parameters.

Like WBEMConnection, FakedWBEMConnection has a default CIM namespace that can be set upon object creation.

FakedWBEMConnection has some additional methods that provide for adding CIM classes, instances and qualifier types to its mock repository. See Building the mock repository for details.

There are no setup methods to remove or modify CIM objects in the mock repository. However, if needed, that can be done by using operation methods such as DeleteClass() or ModifyInstance().

The mock repository supports two operation modes:

full mode: The repository must contain the classes and qualifier types that are needed for the operations that are invoked. This results in a behavior of the faked operations that is close to the behavior of the operations of a real WBEM server.
lite mode: The repository does not need to contain any classes and qualifier types, and can be used when it contains only instances. This simplifies the setup of the mock repository for users, but it also affects the behavior of the faked instance operations to be farther away from the behavior of the operations of a real WBEM server. For example, the faked EnumerateInstances operation will not return instances of subclasses when DeepInheritance is set, because without looking at classes, there is no way it can find out what the subclasses are. And of course, class operations and qualifier operations that retrieve objects don’t work at all if the mock repository does not contain them.

The operation mode of the mock repository is selected when creating a FakedWBEMConnection object, through its repo_lite init parameter. Full mode is the default.

The following example demonstrates setting up a faked connection, adding several CIM objects defined in a MOF string to its mock repository, and executing WBEM operations on the faked connection:

import pywbem
import pywbem_mock

# MOF string defining qualifiers, class, and instance
mof = '''
    Qualifier Key : boolean = false,
        Scope(property, reference),
        Flavor(DisableOverride, ToSubclass);
    Qualifier Description : string = null,
        Scope(any),
        Flavor(EnableOverride, ToSubclass, Translatable);
    Qualifier In : boolean = true,
        Scope(parameter),
        Flavor(DisableOverride, ToSubclass);

        [Description ("This is a dumb test class")]
    class CIM_Foo {
            [Key, Description ("This is key prop")]
        string InstanceID;
            [Description ("This is some simplistic data")]
        Uint32 SomeData;
            [Description ("This is a method without parameters")]
        string Fuzzy();
            [Description ("This is a second method with parameter")]
        uint32 Delete([IN, Description('blahblah']
          boolean Immediate);
    };

    instance of CIM_Foo as $I1 { InstanceID = "I1"; SomeData=3 };
    '''

# Create a faked connection (with a mock repository in full mode)
conn = pywbem_mock.FakedWBEMConnection(default_namespace='root/cimv2')

# Compile the MOF string and add its CIM objects to the default namespace
# of the mock repository
conn.compile_mof_string(mof)

# Perform a few operations on the faked connection:

# Enumerate top-level classes in the default namespace (without subclasses)
classes = conn.EnumerateClasses();
for cls in classes:
    print(cls.tomof())

# Get the 'Description' qualifier type in the default namespace
qd = conn.GetQualifier('Description')

# Enumerate subclasses of 'CIM_Foo' in the default namespace (without subclasses)
classes2 = conn.EnumerateClasses(classname='CIM_Foo')

# Get 'CIM_Foo' class in the default namespace
my_class = conn.GetClass('CIM_Foo')

# Get a specific instance of 'CIM_Foo' in the default namespace
inst = conn.GetInstance(CIMInstanceName('CIM_Foo', {'InstanceID': "I1"})

Pywbem mock supports:

All of the WBEMConnection operation methods that communicate with the WBEM server (see below for list of operations supported and their limitations).
Multiple CIM namespaces and a default namespace on the faked connection.
Gathering time statistics and delaying responses for a predetermined time.
WBEMConnection logging except that there are no HTTP entries in the log.

Pywbem mock does NOT support:

CIM-XML protocol security and security constructor parameters of WBEMConnection.
Dynamic WBEM server providers in that the data for responses is from the mock repository that is built before the request rather than from resources accessed by such providers. This means there is no dynamic determination of property values for newly created CIM instances. Therefore, creating CIM instances requires that all keybinding values as well as all other property values must be provided as input to the CreateInstance() operation by the user.
Processing of queries defined for ExecQuery() in languages like CQL and WQL. The mocked operation parses only the very general portions of the query for class/instance name and properties.
Filter processing of the FQL (see DSP0212) Filter Query Language parameter QueryFilter used by the Open… operations because it does not implement the parser/processor for the FQL language. It returns the same data as if the filter did not exist.
Providing data in the trace variables for last request and last reply in WBEMConnection: last_request, last_raw_request, last_reply, last_raw_reply, last_request_len, or last_reply_len.
Log entries for HTTP request and response in the logging support of WBEMConnection, because it does not actually build the HTTP requests or responses.
Generating CIM indications.
Some of the functionality that may be implemented in real WBEM servers such as the __Namespace__ class/provider or the CIM_Namespace class/provider, because these are WBEM server-specific implementations and not WBEM request level capabilities. Note that such capabilities can be at least partly built on top of the existing capabilities by inserting corresponding CIM instances into the mock repository.

9.2. Faked WBEM operations¶

The pywbem_mock.FakedWBEMConnection class supports the same WBEM operations that are supported by the pywbem.WBEMConnection class.

These faked operations generally adhere to the behavior requirements defined in DSP0200 for handling input parameters and returning a result.

The faked operations get the data to be returned from the mock repository of the faked connection, and put the data provided in operation parameters that modify objects (create, modify, and delete operations) into that mock repository.

However, because the pywbem mock support is only a simulation of a WBEM server and intended to be used primarily for testing, there are a number of limitations and differences between the behavior of the faked operations and a real WBEM server.

The descriptions below describe differences between the faked operations of the pywbem mock support and the operations of a real WBEM server, and the effects of the operation modes of the mock repository.

9.2.1. Faked instance operations¶

Instance operations work in both operation modes of the repository.

The operations that retrieve objects require instances in the repository for the instances to be recovered. We allow some of these methods to try to return data if the class repository is empty but they may react differently if there are classes in the repository.

GetInstance: Behaves like GetInstance(), except that the behavior of property selection for the returned instance when LocalOnly is set depends on the operation mode of the mock repository: In lite mode, property selection is based upon the class_origin attribute of the properties of the instance. In full mode, property selection is based upon the classes in which they are defined.
EnumerateInstances: Behaves like EnumerateInstances(), except for these differences when the mock repository is in lite mode: When DeepInheritance is set, instances of subclasses of the specified class will not be returned, and LocalOnly is ignored and treated as if it was set to False.
EnumerateInstanceNames: Behaves like EnumerateInstances(), except for this difference when the mock repository is in lite mode: When DeepInheritance is set, instances of subclasses of the specified class will not be returned.
CreateInstance: Behaves like CreateInstance(), except for these differences: This operation requires that all key properties are specified in the new instance since the mock repository has no support for dynamically setting key properties as a dynamic provider for the class in a real WBEM server might have. This operation requires that the mock repository is in full mode and that the class of the new instance exists in the mock repository. It fails with not supported if the mock repository is in lite mode.
ModifyInstance: Behaves like ModifyInstance(). This operation requires that the mock repository is in full mode and that the class of the instance exists in the mock repository. It fails with not supported if the mock repository is in lite mode.
DeleteInstance: Behaves like DeleteInstance(), except for this difference depending on the operation mode of the mock repository: In lite mode, the operation does not check for existence of the class of the instance. In full mode, the operation validates the existence of the class of the instance. In the current implementation, this operation does not check for association instances referencing the instance to be deleted, so any such instances become dangling references.
ExecQuery: This operation is not currently implemented. Once implemented: Behaves like ExecQuery(), except that it returns instances based on a very limited parsing of the query string: Generally, the SELECT and FROM clauses are evaluated, and the WHERE clause is ignored. The query string is not validated for correctness. The query language is not validated.

9.2.2. Faked association operations¶

The faked association operations support both instance-level use and class-level use. Class-level use requires the mock repository to be in full mode, while instance-level use works in both operation modes of the mock repository.

AssociatorNames: Behaves like AssociatorNames(), with the following exceptions and requirements: For class-level use, the mock repository must be in full mode and the source, target, and association classes and their subclasses must exist in the mock repository. For instance-level use, correct results are returned if the mock repository is in full mode and the the source, target, and association classes and their subclasses exist in the repository. More limited results are returned in lite mode, because the class hierarchy is not considered when selecting the instances to be returned.
Associators: Behaves like Associators(), with the exceptions and requirements described for AssociatorNames, above.
ReferenceNames: Behaves like ReferenceNames(), with the exceptions and requirements described for AssociatorNames, above.
References: Behaves like References(), with the exceptions and requirements described for AssociatorNames, above.

9.2.3. Faked method invocation operation¶

The faked method invocation operation (InvokeMethod) behaves like InvokeMethod(), but because of the nature of InvokeMethod, the user must provide a callback function that performs the actual task of the CIM method. The mock repository must be in full operation mode.

The callback function must have the signature defined in the method_callback_interface() function and must be registered with the mock repository through add_method_callback() for a particular combination of namespace, class, and CIM method name.

When the callback function is invoked on behalf of an InvokeMethod operation, the target object of the method invocation (class or instance) is provided to the callback function, in addition to the method input parameters.

The callback function can access the mock repository of the faked connection using the normal WBEM operation methods.

The callback function is expected to return a tuple consisting of two items:

the CIM method return value, as a CIM data type value.
a NocaseDict containing any output parameters as CIMParameter objects.

The following is an example for invoking the faked InvokeMethod operation with a simple callback function.

import pywbem
import pywbem_mock

def method1_callback(conn, methodname, objectname, **params):
    """
    Callback function that demonstrates what can be done, without being
    really useful.
    """
    print('params: %r' % params )
    print('object_name %s' % objectname)

    # Access input parameters
    ip1 = params['IP1']

    # Access the mock repository through the faked connection object.
    # In case of a static CIM method, objectname is a
    :class:`~pywbem.CIMClassName` object.
    cl = conn.GetClass(objectname)

    # Set return value and output parameters
    rtn_val = 0
    op1 = CIMParameter('OP1', 'string', value='Some output data')
    return rtn_val, [op1]

mof = '''
    Qualifier In : boolean = true,
        Scope(parameter),
        Flavor(DisableOverride, ToSubclass);

    Qualifier Key : boolean = false,
        Scope(property, reference),
        Flavor(DisableOverride, ToSubclass);

    Qualifier Out : boolean = false,
        Scope(parameter),
        Flavor(DisableOverride, ToSubclass);

    Qualifier Static : boolean = false,
        Scope(property, method),
        Flavor(DisableOverride, ToSubclass);

    class TST_Class {

        string InstanceID;

          [Static,
           Description("Static method with input and output parameters")]
        uint32 Method1(
            [IN, Description("Input param 1")]
          string IP1,
            [IN (false), OUT, Description("Output param 1")]
          string OP1);
    };
'''

# Create a faked connection
conn = pywbem_mock.FakedWBEMConnection(default_namespace='root/cimv2')

# Compile the MOF string and add its CIM objects to the default namespace
# of the mock repository
conn.compile_mof_string(mof)

# Register the method callback function to the mock repository, for the
# default namespace of the connection
conn.add_method_callback('TST_Class', 'Method1', method1_callback)

# Invoke static method Method1
params = [('IP1', 'someData')]
result = conn.InvokeMethod('Method1', 'TST_Class', Params=params)

print('Return value: %r' % result[0])
print('Output parameters: %r' % (result[1],))

9.2.4. Callback functions for faked method invocation¶

The callback functions for faked method invocation must have the following signature:

pywbem_mock.method_callback_interface(conn, methodname, objectname, **params)[source]¶

Interface for user-provided callback functions for CIM method invocation on a faked connection.

Experimental: New in pywbem 0.12 as experimental.

Parameters:	conn (`FakedWBEMConnection`) – Faked connection. This can be used to access the mock repository of the faked connection, via its operation methods (e.g. GetClass). methodname (string) – The CIM method name that is being invoked. This is the method name for which the callback function was registered. This parameter allows a single callback function to be registered for multiple methods. objectname (`CIMInstanceName` or `CIMClassName`) – The object path of the target object of the invoked method, as follows: Instance-level call: The instance path of the target instance, as a `CIMInstanceName` object which has its namespace property set to the target namespace of the invocation. Its host property will not be set. Class-level call: The class path of the target class, as a `CIMClassName` object which has its namespace property set to the target namespace of the invocation. Its host property will not be set. params (NocaseDict) – The input parameters for the method that were passed to the InvokeMethod operation. Each dictionary item represents a single input parameter for the CIM method and is a `CIMParameter` object, regardless of how the input parameter was passed to the `InvokeMethod()` method. The `CIMParameter` object will have at least the following properties set: name (string): Parameter name (case independent). type (string): CIM data type of the parameter. value (CIM data type): Parameter value.
Returns:	The callback function must return a tuple consisting of: return_value (CIM data type): Return value for the CIM method. out_params (iterable of `CIMParameter`): Each item represents a single output parameter of the CIM method. The `CIMParameter` objects must have at least the following properties set: name (string): Parameter name (case independent). type (string): CIM data type of the parameter. value (CIM data type): Parameter value.
Return type:	tuple
Raises:	Since the callback function mocks a CIM method invocation, it should raise `CIMError` exceptions to indicate failures. Any other exceptions raised by the callback function will be mapped to `CIMError` exceptions with status CIM_ERR_FAILED and a message that contains information about the exception including a traceback.

9.2.5. Faked pull operations¶

The faked pull operations behave like the pull operations of WBEMConnection, with the following exceptions:

The filter query related parameters FilterQuery and FilterQueryLanguage are ignored and no such filtering takes place.
The ContinueOnError parameter is ignored because injecting an error into the processing of the pull operations is not supported by the pywbem mock support, so no failures can happen during the processing of the pull operations.
The OperationTimeout parameter is currently ignored. As a result, there will be no timeout if the response_delay property is set to a time larger than the OperationTimeout parameter.

The faked pull operations are:

OpenEnumerateInstances: Behaves like OpenEnumerateInstances(), with the stated exceptions.
OpenEnumerateInstancePaths: Behaves like OpenEnumerateInstancePaths(), with the stated exceptions.
OpenAssociatorInstances: Behaves like OpenAssociatorInstances(), with the stated exceptions.
OpenAssociatorInstancePaths: Behaves like OpenAssociatorInstancePaths(), with the stated exceptions.
OpenReferenceInstances: Behaves like OpenReferenceInstances(), with the stated exceptions.
OpenReferenceInstancePaths: Behaves like OpenReferenceInstancePaths(), with the stated exceptions.
OpenQueryInstances: Behaves like OpenQueryInstances(), with the stated exceptions.
PullInstancesWithPath: Behaves like PullInstancesWithPath(), with the stated exceptions.
PullInstancePaths: Behaves like PullInstancePaths(), with the stated exceptions.
PullInstances: Behaves like PullInstances(), with the stated exceptions.
CloseEnumeration: Behaves like CloseEnumeration(), with the stated exceptions.

9.2.6. Faked iter operations¶

The iter operations on a faked connection are in fact the iter operations on WBEMConnection, because they do not directly issue requests and responses on the connection, but instead are simply a layer on top of underlying operations. For example, IterEnumerateInstances invokes either pull operations (i.e. OpenEnumerateInstances followed by PullInstancesWithPath) or traditional operations (i.e. EnumerateInstances). The use of pull vs. traditional operations is controlled via the use_pull_operations init parameter of FakedWBEMConnection.

The iter operations are:

9.2.7. Faked class operations¶

Class operations only work if the mock repository is in full operation mode.

GetClass: Behaves like GetClass(). Requires that the class to be returned is in the mock repository.
EnumerateClasses: Behaves like EnumerateClasses(). Requires that the class specified in the ClassName parameter as well as the classes to be returned are in the mock repository.
EnumerateClassNames: Behaves like EnumerateClassNames(). Requires that the class specified in the ClassName parameter as well as the classes to be returned are in the mock repository.
CreateClass: Behaves like CreateClass(). Requires that the superclass of the new class (if it specifies one) is in the mock repository.
DeleteClass: Behaves like DeleteClass(), with the following difference: This operation additionally deletes all direct and indirect subclasses of the class to be deleted, and all instances of the classes that are being deleted. Requires that the class to be deleted is in the mock repository.
ModifyClass: Not currently implemented.

9.2.8. Faked qualifier operations¶

Qualifier operations only work if the mock repository is in full operation mode.

SetQualifier: Behaves like SetQualifier(). Requires that the specified qualifier type is in the mock repository.
GetQualifier: Behaves like GetQualifier(). Requires that the specified qualifier type is in the mock repository.
EnumerateQualifiers: Behaves like EnumerateQualifiers(). Requires that the qualifier types to be returned are in the mock repository.

9.3. Building the mock repository¶

The mock repository should contain the CIM qualifier declarations, CIM classes, CIM instances, and CIM methods to be used in the mock environment. The mock user creates a repository that contains the CIM objects required for the operations to be executed in the mock environment. Thus, if the user only requires CIM_ComputerSystem, only that class and its dependent classes need be in the repository along with instances of the classes that will satisfy the methods called

FakedWBEMConnection and DMTFCIMSchema provide the tools to build the mock repository.

There are two ways to build a mock repository:

Directly from pywbem CIM objects (CIMClass, CIMInstance, etc). See add_cimobjects()
From MOF definitions of the objects (which can be a string or a file, in and with MOF pragma include statements).

There are two methods to help building the repository from MOF:
- Build from MOF definitions of the objects which are compiled into the repository. See compile_mof_string() and See compile_mof_file().
- Build MOF qualifier declarations and classes directly from the DMTF CIM schema by downloading the schema from the DMTF and selecting all or part of the schema to compile. This automatically compiles all qualifiers declarations into the mock repository and allows setting up a partial class repository (i.e. just selected classes) in a single method. See section DMTF CIM schema download support and the compile_dmtf_schema() method.

It may take a combination of all three of the above methods to build a schema that satisfies a particular requirement including:

Build the DMTF CIM Classes from the DMTF schema. This is easy to code, and eliminates errors defining components. It also loads all qualifier declarations.
Build non-DMTF classes (subclasses, etc.) by defining either MOF for the classes and compiling or directly building the pywbem CIM classes.
Build CIM instances by defining MOF and compiling or directly building the pywbem CIM instances. Often MOF is easier for this because it simplifies the definition of association instances with the instance alias.
Add the definition of any CIM methods for which the mock server is expected to respond. add_method_callback. See add_method_callback().

The pywbem MOF compiler provides support for:

Automatically including all qualifier declaractions if classes are added with the method compile_dmtf_schema() or the DMTFCIMSchema.
Adding dependent classes from the DMTF schema in the case where they are missing in the compiled mof and the compiler search path includes the MOF directory of the DMTF CIM schema. This include superclasses, reference classes defined in reference properties and parameters, and the class referenced through the EmbeddedInstance qualifier. Thus, the user does not have to track down those dependent classes to be able to create a working mock repository.

9.3.1. Example: Set up qualifier types and classes in DMTF CIM schema¶

This example creates a faked connection and compiles the classes defined in the list ‘classes’ from DMTF schema version 2.49.0 into the repository along with all of the qualifier declarations defined by the DMTF schema and any dependent classes (superclasses, etc.).

import pywbem
import pywbem_mock

conn = pywbem_mock.FakedWBEMConnection(default_namespace='root/interop')

# Leaf classes that are to be compiled along with their dependent classes
leaf_classes = ['CIM_RegisteredProfile',
                'CIM_Namespace',
                'CIM_ObjectManager',
                'CIM_ElementConformsToProfile',
                'CIM_ReferencedProfile']

# Compile dmtf schema version 2.49.0, the qualifier declarations and
# the classes in 'classes' and all dependent classes and keep the
# schema in directory my_schema_dir
conn.compile_dmtf_schema((2, 49, 0), "my_schema_dir", classes,
                        verbose=True)

# Display the resulting repository
conn.display_repository()

9.3.2. Example: Set up qualifier types and classes from MOF¶

This example creates a faked connection and sets up its mock repository with qualifier types and classes that are defined in a MOF string.

import pywbem
import pywbem_mock

tst_namespace = 'root/blah'
conn = pywbem_mock.FakedWBEMConnection()

# Add some qualifier types and classes to the mock repo by compiling MOF
mof = '''
    Qualifier Key : boolean = false,
        Scope(property, reference),
        Flavor(DisableOverride, ToSubclass);

    Qualifier Association : boolean,
        Scope(class),
        Flavor(DisableOverride, ToSubclass);

    class TST_Class1 {
          [Key]
        string InstanceID;
        string Prop1;
    };

    class TST_Class2 {
          [Key]
        string InstanceID;
        string Prop2;
    };

      [Association]
    class TST_Association12 {
          [Key]
        TST_Class1 REF Ref1;
          [Key]
        TST_Class2 REF Ref2;
    };
'''
conn.compile_mof_string(mof, tst_namespace)

conn.display_repository()

This code displays the mock repository in MOF format after adding these objects:

# ========Mock Repo Display fmt=mof namespaces=all =========


# NAMESPACE root/blah

# Namespace root/blah: contains 2 Qualifier Declarations

Qualifier Association : boolean,
    Scope(class),
    Flavor(DisableOverride, ToSubclass);

Qualifier Key : boolean = false,
    Scope(property, reference),
    Flavor(DisableOverride, ToSubclass);

# Namespace root/blah: contains 3 Classes

   [Association ( true )]
class TST_Association12 {

      [Key ( true )]
   TST_Class1 REF Ref1;

      [Key ( true )]
   TST_Class2 REF Ref2;

};

class TST_Class1 {

      [Key ( true )]
   string InstanceID;

   string Prop1;

};

class TST_Class2 {

      [Key ( true )]
   string InstanceID;

   string Prop2;

};

============End Repository=================

9.3.3. Example: Set up instances from single CIM objects¶

Based on the mock repository content of the previous example, this example adds two class instances and one association instance from their CIM objects.

c1_key = pywbem.CIMProperty('InstanceID', type='string', value='111')
c1_path = pywbem.CIMInstanceName(
    'TST_Class1',
    keybindings={c1_key.name: c1_key.value},
)
c1 = pywbem.CIMInstance(
    'TST_Class1',
    properties=[
        c1_key,
        pywbem.CIMProperty('Prop1', type='string', value='1'),
    ],
    path=c1_path,
)

c2_key = pywbem.CIMProperty('InstanceID', type='string', value='222')
c2_path = pywbem.CIMInstanceName(
    'TST_Class2',
    keybindings={c2_key.name: c2_key.value},
)
c2 = pywbem.CIMInstance(
    'TST_Class2',
    properties=[
        c2_key,
        pywbem.CIMProperty('Prop2', type='string', value='2'),
    ],
    path=c2_path,
)

a12_key1 = pywbem.CIMProperty('Ref1', type='reference', value=c1_path)
a12_key2 = pywbem.CIMProperty('Ref2', type='reference', value=c2_path)
a12_path = pywbem.CIMInstanceName(
    'TST_Association12',
    keybindings={
        a12_key1.name: a12_key1.value,
        a12_key2.name: a12_key2.value,
    },
)
a12 = pywbem.CIMInstance(
    'TST_Association12',
    properties=[
        a12_key1,
        a12_key2,
    ],
    path=a12_path,
)

conn.add_cimobjects([c1, c2, a12], tst_namespace)

conn.display_repository()

This adds the instances to the repository display of the previous example:

# Namespace root/blah: contains 3 Instances

#  Path=/root/blah:TST_Class1.InstanceID="111"
instance of TST_Class1 {
   InstanceID = "111";
   Prop1 = "1";
};

#  Path=/root/blah:TST_Class2.InstanceID="222"
instance of TST_Class2 {
   InstanceID = "222";
   Prop2 = "2";
};

#  Path=/root/blah:TST_Association12.Ref1="/:TST_Class1.InstanceID=\"111\"",Ref2="/:TST_Class2.InstanceID=\"222\""
instance of TST_Association12 {
   Ref1 = "/:TST_Class1.InstanceID=\"111\"";
   Ref2 = "/:TST_Class2.InstanceID=\"222\"";
};

9.4. FakedWBEMConnection¶

class pywbem_mock.FakedWBEMConnection(default_namespace='root/cimv2', use_pull_operations=False, stats_enabled=False, timeout=None, response_delay=None, repo_lite=False)[source]¶

A subclass of pywbem.WBEMConnection that mocks the communication with a WBEM server by utilizing a local in-memory mock repository to generate responses in the same way the WBEM server would.

Experimental: New in pywbem 0.12 as experimental.

For a description of the operation methods on this class, see Faked WBEM operations.

Each FakedWBEMConnection object has its own mock repository which contains multiple CIM namespaces, and each namespace may contain CIM qualifier types (declarations), CIM classes and CIM instances.

This class provides only a subset of the init parameters of WBEMConnection because it does not have a connection to a WBEM server. It uses a faked and fixed URL for the WBEM server (http://FakedUrl) as a means of identifying the connection by users.

Logging of the faked operations is supported via the pywbem logging facility and can be controlled in the same way as for WBEMConnection. For details, see WBEM operation logging.

Parameters:

default_namespace (string) – Default namespace. This parameter has the same characteristics as the same-named init parameter of WBEMConnection.
use_pull_operations (bool) – Flag to control whether pull or traditional operaitons are used in the iter operations. This parameter has the same characteristics as the same-named init parameter of WBEMConnection.
timeout (number) – This parameter has the same characteristics as the same-named init parameter of WBEMConnection.
stats_enabled (bool) – Flag to enable operation statistics. This parameter has the same characteristics as the same-named init parameter of WBEMConnection.
response_delay (number) –
Artifically created delay for each operation, in seconds. This must be a positive number. Delays less than a second or other fractional delays may be achieved with float numbers. None disables the delay.

Note that the response_delay property can be used to set this delay subsequent to object creation.
repo_lite (bool) – Flag to set the operation mode of the mock repository. If True, lite mode is set. If False, full mode is set.

Methods

`AssociatorNames`	Retrieve the instance paths of the instances associated to a source instance, or the class paths of the classes associated to a source class.
`Associators`	Retrieve the instances associated to a source instance, or the classes associated to a source class.
`CloseEnumeration`	Close an open enumeration session, causing an early termination of an incomplete enumeration session.
`CreateClass`	Create a class in a namespace.
`CreateInstance`	Create an instance in a namespace.
`DeleteClass`	Delete a class.
`DeleteInstance`	Delete an instance.
`DeleteQualifier`	Delete a qualifier type (= qualifier declaration).
`EnumerateClassNames`	Enumerate the names of subclasses of a class, or of the top-level classes in a namespace.
`EnumerateClasses`	Enumerate the subclasses of a class, or the top-level classes in a namespace.
`EnumerateInstanceNames`	Enumerate the instance paths of instances of a class (including instances of its subclasses) in a namespace.
`EnumerateInstances`	Enumerate the instances of a class (including instances of its subclasses) in a namespace.
`EnumerateQualifiers`	Enumerate the qualifier types (= qualifier declarations) in a namespace.
`ExecQuery`	Execute a query in a namespace.
`GetClass`	Retrieve a class.
`GetInstance`	Retrieve an instance.
`GetQualifier`	Retrieve a qualifier type (= qualifier declaration).
`InvokeMethod`	Invoke a method on a target instance or on a target class.
`IterAssociatorInstancePaths`	Retrieve the instance paths of the instances associated to a source instance, using the Python generator idiom to return the result.
`IterAssociatorInstances`	Retrieve the instances associated to a source instance, using the Python generator idiom to return the result.
`IterEnumerateInstancePaths`	Enumerate the instance paths of instances of a class (including instances of its subclasses) in a namespace, using the Python generator idiom to return the result.
`IterEnumerateInstances`	Enumerate the instances of a class (including instances of its subclasses) in a namespace, using the Python generator idiom to return the result.
`IterQueryInstances`	Execute a query in a namespace, using the Python generator idiom to return the result.
`IterReferenceInstancePaths`	Retrieve the instance paths of the association instances that reference a source instance, using the Python generator idiom to return the result.
`IterReferenceInstances`	Retrieve the association instances that reference a source instance, using the Python generator idiom to return the result.
`ModifyClass`	Modify a class.
`ModifyInstance`	Modify the property values of an instance.
`OpenAssociatorInstancePaths`	Open an enumeration session to retrieve the instance paths of the instances associated to a source instance.
`OpenAssociatorInstances`	Open an enumeration session to retrieve the instances associated to a source instance.
`OpenEnumerateInstancePaths`	Open an enumeration session to enumerate the instance paths of instances of a class (including instances of its subclasses) in a namespace.
`OpenEnumerateInstances`	Open an enumeration session to enumerate the instances of a class (including instances of its subclasses) in a namespace.
`OpenQueryInstances`	Open an enumeration session to execute a query in a namespace and to retrieve the instances representing the query result.
`OpenReferenceInstancePaths`	Open an enumeration session to retrieve the instance paths of the association instances that reference a source instance.
`OpenReferenceInstances`	Open an enumeration session to retrieve the association instances that reference a source instance.
`PullInstancePaths`	Retrieve the next set of instance paths from an open enumeration session.
`PullInstances`	Retrieve the next set of instances (without instance paths) from an open enumeration session.
`PullInstancesWithPath`	Retrieve the next set of instances (with instance paths) from an open enumeration session.
`ReferenceNames`	Retrieve the instance paths of the association instances that reference a source instance, or the class paths of the association classes that reference a source class.
`References`	Retrieve the association instances that reference a source instance, or the association classes that reference a source class.
`SetQualifier`	Create or modify a qualifier type (= qualifier declaration) in a namespace.
`add_cimobjects`	Add CIM classes, instances and/or CIM qualifier types (declarations) to the specified CIM namespace of the mock repository.
`add_method_callback`	Register a callback function for a CIM method that will be called when the CIM method is invoked via InvokeMethod.
`add_namespace`	Add a CIM namespace to the mock repository.
`add_operation_recorder`	Experimental: Add an operation recorder to this connection.
`compile_dmtf_schema`	Compile the classes defined by class_names and their dependent classes from the DMTF CIM schema version defined by schema_version and keep the downloaded DMTF CIM schema in the directory defined by schema_dir.
`compile_mof_file`	Compile the MOF definitions in the specified file (and its included files) and add the resulting CIM objects to the specified CIM namespace of the mock repository.
`compile_mof_string`	Compile the MOF definitions in the specified string and add the resulting CIM objects to the specified CIM namespace of the mock repository.
`display_repository`	Display the namespaces and objects in the mock repository in one of multiple formats to a destination.
`imethodcall`	Deprecated: Low-level method used by the operation-specific methods of this class.
`methodcall`	Deprecated: Low-level method used by the `InvokeMethod()` method of this class.
`operation_recorder_reset`	Experimental: Low-level method used by the operation-specific methods of this class.
`operation_recorder_stage_pywbem_args`	Experimental: Low-level method used by the operation-specific methods of this class.
`operation_recorder_stage_result`	Experimental: Low-level method used by the operation-specific methods of this class.

Attributes

`ca_certs`	string – Location of CA certificates (trusted certificates) for verifying the X.509 server certificate returned by the WBEM server.
`conn_id`	connection id – Connection ID (a unique ID) of this connection.
`creds`	`tuple()` – Credentials for HTTP authentication with the WBEM server.
`debug`	`bool` – Boolean indicating that debug is enabled for this connection.
`default_namespace`	unicode string – Name of the CIM namespace to be used by default (if no namespace is specified for an operation).
`host`	unicode string – The `{host}[:{port}]` component of the WBEM server’s URL, as specified in the `url` attribute.
`last_operation_time`	`float` – Elapsed time of the last operation that was executed via this connection in seconds or None.
`last_raw_reply`	unicode string – CIM-XML data of the last response received from the WBEM server on this connection, formatted as it was received (=raw).
`last_raw_request`	unicode string – CIM-XML data of the last request sent to the WBEM server on this connection, formatted as it was sent (=raw).
`last_reply`	unicode string – CIM-XML data of the last response received from the WBEM server on this connection, formatted as prettified XML.
`last_reply_len`	`int` – The size of the HTTP body in the CIM-XML response of the last operation, in Bytes.
`last_request`	unicode string – CIM-XML data of the last request sent to the WBEM server on this connection, formatted as prettified XML.
`last_request_len`	`int` – The size of the HTTP body in the CIM-XML request of the last operation, in Bytes.
`last_server_response_time`	`float` – Server-measured response time of the last request, or None.
`no_verification`	`bool` – Boolean indicating that verifications are disabled for this connection.
`operation_recorder`	`BaseOperationRecorder` – Deprecated: The operation recorder that was last added to the connection, or None if the connection does not currently have any recorders.
`operation_recorder_enabled`	`bool` – Experimental: Enablement status for all operation recorders of the connection.
`operation_recorders`	Tuple of `BaseOperationRecorder` subclass objects – Experimental: The operation recorders of this connection.
`response_delay`	number – Artifically created delay for each operation, in seconds.
`statistics`	`Statistics` – Statistics for this connection.
`stats_enabled`	`bool` – Statistics enablement status for this connection.
`timeout`	number – Timeout in seconds, for requests sent to the server.
`url`	unicode string – URL of the WBEM server.
`use_pull_operations`	`bool` – Boolean indicating that the client should attempt the use of pull operations in any Iter…() methods.
`verify_callback`	callable – Callback function that will be called to verify the X.509 server certificate returned by the WBEM server during the TLS/SSL handshake, in addition to the validation already performed by the TLS/SSL support.
`x509`	`dict` – X.509 client certificate and key file to be presented to the WBEM server during the TLS/SSL handshake.

Details

response_delay¶

number – Artifically created delay for each operation, in seconds. If None, there is no delay.

This attribute is settable. For details, see the description of the same-named init parameter of this class.

add_namespace(namespace)[source]¶

Add a CIM namespace to the mock repository.

The namespace must not yet exist in the mock repository.

Note that the default connection namespace is automatically added to the mock repository upon creation of this object.

Parameters:	namespace (string) – The name of the CIM namespace in the mock repository. Must not be None. Any leading and trailing slash characters are split off from the provided string.
Raises:	`ValueError` – Namespace argument must not be None `CIMError` – CIM_ERR_ALREADY_EXISTS if the namespace already exists in the mock repository.

compile_mof_file(mof_file, namespace=None, search_paths=None, verbose=None)[source]¶

Compile the MOF definitions in the specified file (and its included files) and add the resulting CIM objects to the specified CIM namespace of the mock repository.

If the namespace does not exist, CIMError with status CIM_ERR_INVALID_NAMESPACE is raised.

This method supports all MOF pragmas, and specifically the include pragma.

If a CIM class or CIM qualifier type to be added already exists in the target namespace with the same name (comparing case insensitively), this method raises CIMError.

If a CIM instance to be added already exists in the target namespace with the same keybinding values, this method raises CIMError.

In all cases where this method raises an exception, the mock repository remains unchanged.

Parameters:

mof_file (string) – Path name of the file containing the MOF definitions to be compiled.
namespace (string) – The name of the target CIM namespace in the mock repository. This namespace is also used for lookup of any existing or dependent CIM objects. If None, the default namespace of the connection is used.
search_paths (iterable of string) – An iterable of directory path names where MOF dependent files will be looked up. See the description of the search_path init parameter of the MOFCompiler class for more information on MOF dependent files.
verbose (bool) – Controls whether to issue more detailed compiler messages.

Raises:

IOError – MOF file not found.
MOFParseError – Compile error in the MOF.
CIMError – CIM_ERR_INVALID_NAMESPACE: Namespace does not exist.
CIMError – Failure related to the CIM objects in the mock repository.

compile_mof_string(mof_str, namespace=None, search_paths=None, verbose=None)[source]¶

Compile the MOF definitions in the specified string and add the resulting CIM objects to the specified CIM namespace of the mock repository.

If the namespace does not exist, CIMError with status CIM_ERR_INVALID_NAMESPACE is raised.

This method supports all MOF pragmas, and specifically the include pragma.

If a CIM class or CIM qualifier type to be added already exists in the target namespace with the same name (comparing case insensitively), this method raises CIMError.

If a CIM instance to be added already exists in the target namespace with the same keybinding values, this method raises CIMError.

In all cases where this method raises an exception, the mock repository remains unchanged.

Parameters:

mof_str (string) – A string with the MOF definitions to be compiled.
namespace (string) – The name of the target CIM namespace in the mock repository. This namespace is also used for lookup of any existing or dependent CIM objects. If None, the default namespace of the connection is used.
search_paths (iterable of string) – An iterable of directory path names where MOF dependent files will be looked up. See the description of the search_path init parameter of the MOFCompiler class for more information on MOF dependent files.
verbose (bool) – Controls whether to issue more detailed compiler messages.

Raises:

IOError – MOF file not found.
MOFParseError – Compile error in the MOF.
CIMError – CIM_ERR_INVALID_NAMESPACE: Namespace does not exist.
CIMError – Failure related to the CIM objects in the mock repository.

compile_dmtf_schema(schema_version, schema_root_dir, class_names, use_experimental=False, namespace=None, verbose=False)[source]¶

Compile the classes defined by class_names and their dependent classes from the DMTF CIM schema version defined by schema_version and keep the downloaded DMTF CIM schema in the directory defined by schema_dir.

This method uses the DMTFCIMSchema class to download the DMTF CIM schema defined by schema_version from the DMTF, into the schema_root_dir directory, extract the MOF files, create a MOF file with the #include pragma statements for the files in class_names and attempt to compile this set of files.

It automatically compiles all of the DMTF qualifier declarations that are in the files qualifiers.mof and qualifiers_optional.mof.

The result of the compilation is added to the specified CIM namespace of the mock repository.

If the namespace does not exist, CIMError with status CIM_ERR_INVALID_NAMESPACE is raised.

Parameters:

schema_version (tuple of 3 integers (m, n, u) –
Represents the DMTF CIM schema version where:
- m is the DMTF CIM schema major version
- n is the DMTF CIM schema minor version
- u is the DMTF CIM schema update version
This must represent a DMTF CIM schema that is available from the DMTF web site.
schema_root_dir (string) –
Directory into which the DMTF CIM schema is installed or will be installed. A single schema_dir can be used for multiple schema versions because subdirectories are uniquely defined by schema version and schema_type (i.e. Final or Experimental).

Multiple DMTF CIM schemas may be maintained in the same schema_root_dir simultaneously because the MOF for each schema is extracted into a subdirectory identified by the schema version information.
class_names (list of string or string) –
List of class names from the DMTF CIM Schema to be included in the repository.

A single class may be defined as a string not in a list.

These must be classes in the defined DMTF CIM schema and can be a list of just the leaf classes required The MOF compiler will search the DMTF CIM schema MOF classes for superclasses, classes defined in reference properties, and classes defined in EmbeddedInstance qualifiers and compile them also.
use_experimental (bool) –
If True the expermental version of the DMTF CIM Schema is installed or to be installed.

If False (default) the final version of the DMTF CIM Schema is installed or to be installed.
namespace (string) – The name of the target CIM namespace in the mock repository. This namespace is also used for lookup of any existing or dependent CIM objects. If None, the default namespace of the connection is used.
verbose (bool) – If True, progress messages are output to stdout

Raises:

ValueError – The schema cannot be retrieved from the DMTF web site, the schema_version is invalid, or a class name cannot be found in the defined DMTF CIM schema.
TypeError – The ‘schema_version’ is not a valid tuple with 3 integer components
MOFParseError – Compile error in the MOF.
CIMError – CIM_ERR_INVALID_NAMESPACE: Namespace does not exist.
CIMError – Failure related to the CIM objects in the mock repository.

add_cimobjects(objects, namespace=None)[source]¶

Add CIM classes, instances and/or CIM qualifier types (declarations) to the specified CIM namespace of the mock repository.

This method adds a copy of the objects presented so that the user may modify the objects without impacting the repository.

If the namespace does not exist, CIMError with status CIM_ERR_INVALID_NAMESPACE is raised.

The method imposes very few limits on the objects added. It does require that the superclass exist for any class added and that instances added include a path component. If the qualifier flavor attributes are not set, it sets them to those defined in the Qualifier Declarations if those exist.

If a CIM class or CIM qualifier type to be added already exists in the target namespace with the same name (comparing case insensitively), this method fails, and the mock repository remains unchanged.

If a CIM instance to be added already exists in the target namespace with the same keybinding values, this method fails, and the mock repository remains unchanged.

Parameters:

objects (CIMClass or CIMInstance or CIMQualifierDeclaration, or list of them) – CIM object or objects to be added to the mock repository. The list may contain different kinds of CIM objects.
namespace (string) – The name of the target CIM namespace in the mock repository. This namespace is also used for lookup of any existing or dependent CIM objects. If None, the default namespace of the connection is used.

Raises:

ValueError – Invalid input CIM object in objects parameter.
TypeError – Invalid type in objects parameter.
CIMError – CIM_ERR_INVALID_NAMESPACE: Namespace does not exist.
CIMError – Failure related to the CIM objects in the mock repository.

add_method_callback(classname, methodname, method_callback, namespace=None)[source]¶

Register a callback function for a CIM method that will be called when the CIM method is invoked via InvokeMethod.

If the namespace does not exist, CIMError with status CIM_ERR_INVALID_NAMESPACE is raised.

Parameters:

classname (string) –
The CIM class name for which the callback function is registered.

The faked InvokeMethod implementation uses this information to look up the callback function from its parameters.

For method invocations on a target instance, this must be the class name of the creation class of the target instance.

For method invocations on a target class, this must be the class name of the target class.
methodname (string) –
The CIM method name for which the callback function is registered.

The faked InvokeMethod implementation uses this information to look up the callback function from its parameters.
method_callback (method_callback_interface()) – The callback function.
namespace (string) –
The CIM namespace for which the callback function is registered.

If None, the callback function is registered for the default namespace of the connection.

The faked InvokeMethod implementation uses this information to look up the callback function from its parameters.

Raises:

ValueError – Duplicate method specification.
CIMError – CIM_ERR_INVALID_NAMESPACE: Namespace does not exist.

display_repository(namespaces=None, dest=None, summary=False, output_format='mof')[source]¶

Display the namespaces and objects in the mock repository in one of multiple formats to a destination.

Parameters:

namespaces (string or list of string) – Limits display output to the specified CIM namespace or namespaces. If None, all namespaces of the mock repository are displayed.
dest (string) – File path of the output file. If None, the output is written to stdout.
summary (bool) – Flag for summary mode. If True, only a summary count of CIM objects in the specified namespaces of the mock repository is produced. If False, both the summary count and the details of the CIM objects are produced.
output_format (string) – Output format, one of: ‘mof’, ‘xml’, or ‘repr’.

9.5. DMTF CIM schema download support¶

A DMTF CIM schema is the collection of CIM qualifier declarations and CIM classes managed by the DMTF and released as a single tested, coherent package with a defined major, minor, update version number. The MOF representation of a DMTF schema release is packaged as a single zip file and is available on the DMTF web site ( https://www.dmtf.org/standards/cim ).

Because the DMTF CIM schemas are the source of most of the classes that a WBEM server normally implements it was important to create a simple mechanism to include the DMTF CIM classes and qualifier declarations in the FakedWBEMConnection mock repository.

The DMTFCIMSchema class downloads the DMTF CIM schema zip file defined by version from the DMTF web site into a defined directory, unzips the MOF files into a subdirectory and makes this subdirectory available as a property of the DMTFCIMSchema object.

The implementation of this class depends on all of the qualiifiers and classes in the CIM schema having unique class names; this is always true for DMTF CIM schema releases to assure that they can be installed in the same namespace in a WBEM server repository.

Once a DMTF CIM schema is extracted into the individual MOF files it consumes considerable space since it expands to almost 3000 files. Therefore it is logical to remove all of the individual MOF files when not being used and also if the schema information is to be committed to be used in testing in an environment like github. Therefore, a method clean() removes all of the MOF files from local storage. They are restored the next time the DMTFCIMSchema object for the same version is constructed.

The DMTF maintains two versions of each released schema:

Final - This schema does not contain any of the schema classes that are marked experimental. It is considered the stable release.
Experimental - Contains the classes in the final schema plus other classes that are considered experimental. It is considered less stable and the experimental classes with the Experimental qualifier are subject to incompatible changes .

DMTFCIMSchema will install either the final or experimental schema depending on the value of the use_experimental parameter.

Because it is usually necessary to compile only a subset of the DMTF CIM classes into a mock repository for any test, the DMTFCIMSchema class provides a build_schema_mof() method to create a MOF include file that includes only a subset of the classes in the downloaded DMTF CIM Schema. The task of listing classes to be compiled is futher simplified because the pywbem MOF compiler searches the DMTF schema for prerequisite classes (superclasses, reference classes, and EmbeddedInstance classes) so that generally only the leaf CIM classes required for the repository need to be in the class list. This speeds up the process of compiling DMTF CIM classes for any test significantly.

class pywbem_mock.DMTFCIMSchema(schema_version, schema_root_dir, use_experimental=False, verbose=False)[source]¶

DMTFCIMSchema represents a DMTF CIM Schema downloaded from the DMTF web site.

This class manages the download of the DMTF schema zip file and extraction of MOF files of DMTF CIM schema releases into a directory that can be used by FakedWBEMConnection to compile a mock repository with class and qualifier declarations.

The init method downloads the schema if the schema_root_dir or the schema zip file do not exist into the directory defined by the schema_root_dir parameter and extracts the MOF files into schema_mof_dir.

If the schema zip file is already downloaded it simply sets the DMTFCIMSchema property values.

If the schema zip file was previously downloaded but schema_mof_dir does not exist the directory is created and the MOF files are extracted into this directory.

Parameters:

schema_version (tuple of 3 integers (m, n, u) –
Represents the DMTF CIM schema version m.n.u where:
- m is the DMTF CIM schema major version
- n is the DMTF CIM schema minor version
- u is the DMTF CIM schema update version
This must represent a DMTF CIM schema that is available from the DMTF web site.
schema_root_dir (string) –
Path name of the schema root directory into which the DMTF CIM schema zip file is downloaded and in which a subdirectory for the extracted MOF files is created

Multiple DMTF CIM schemas may be maintained in the same schema_root_dir simultaneously because the MOF for each schema is extracted into a subdirectory identified by the schema version information.
use_experimental (bool) –
If True, the experimental version of the defined DMTF schema is installed.

If False, (default) the final version of the defined DMTF schema is installed.
verbose (bool) – If True, progress messages are output to stdout as the schema is downloaded and expanded. Default is False.

Raises:

ValueError – if the schema cannot be retrieved from the DMTF web site.
TypeError – if the schema_version is not a valid tuple with 3 integer components

Methods

`build_schema_mof`	Build a string that includes the `#include pragma` statements for the DMTF schema CIM classes defined in schema_classes using the DMTF CIM schema defined by this object.
`clean`	Remove all of the MOF files and the schema_mof_dir for the defined schema.
`remove`	The schema_mof_dir directory is removed if it esists and the schema_zip_file is removed if it exists.

Attributes

`schema_mof_dir`	string – Path name of the directory in which the DMTF CIM Schema MOF files are extracted from the downloaded zip file.
`schema_mof_file`	string – Path name of the DMTF CIM schema MOF top level file which used to compile the complete CIM schema.
`schema_root_dir`	string – Path name of the directory in which the DMTF CIM Schema zip file is downloaded.
`schema_version`	`tuple()` – of 3 integers with major version, minor version, and update version of the DMTF Schema installed.
`schema_version_str`	string – with the DMTF CIM schema version in the form <major version>.<minor version>.<update version>.
`schema_zip_file`	string – Path name of the DMTF CIM schema zip file downloaded from the DMTF web site.
`schema_zip_url`	string – Url for the DMTF CIM Schema version that is downloaded.

Details

schema_version¶: tuple() – of 3 integers with major version, minor version, and update version of the DMTF Schema installed. Ex (2, 49, 0) defines DMTF schema version 2.49.0.

schema_version_str¶: string – with the DMTF CIM schema version in the form <major version>.<minor version>.<update version>.

schema_root_dir¶: string – Path name of the directory in which the DMTF CIM Schema zip file is downloaded. the MOF files are extracted into a subdirectory, schema_mof_dir.

schema_mof_dir¶: string – Path name of the directory in which the DMTF CIM Schema MOF files are extracted from the downloaded zip file. This property is useful since it can be used as the MOF compiler search path for compiling classes in the DMTF CIM schema.

schema_mof_file¶

string – Path name of the DMTF CIM schema MOF top level file which used to compile the complete CIM schema. This file contains the #pragama include statements for all of the classes in the schema and the qualifier declaration #pragma include statements to compile qualifiers.mof and qualifiers_optional.mof.

This filename is of the general form:

<schema_mof_dir>/cim_schema_<schema_version_str>.mof

ex: schemas/dmtf/moffinal2490/cim_schema_2.49.0.mof

schema_zip_file¶: string – Path name of the DMTF CIM schema zip file downloaded from the DMTF web site.

schema_zip_url¶: string – Url for the DMTF CIM Schema version that is downloaded.

__str__()[source]¶: Return a short string representation of the DMTFCIMSchema object for human consumption. This displays the major properties of the object.

__repr__()[source]¶: Return a string representation of the DMTFCIMSchema object that is suitable for debugging.

build_schema_mof(schema_classes)[source]¶

Build a string that includes the #include pragma statements for the DMTF schema CIM classes defined in schema_classes using the DMTF CIM schema defined by this object.

The class names in this list can be just leaf classes. The pywbem MOF compiler will search for dependent classes.

It builds a compilable MOF string in the form:

#pragma locale ("en_US")
#pragma include ("System/CIM_ComputerSystem.mof")

with a #pragma include for each classname in the schema_classes list

Parameters:	schema_classes (list of string or string) – These must be class names of classes in the DMTF CIM schema represented by this `DMTFCIMSchema` object. This parameter can be a string if there is only a single class name to be included. If the returned string is compiled, the MOF compiler will search the directory defined by schema_mof_dir for dependent classes.
Returns:	Valid MOF containing pragma statements for all of the classes in schema_classes.
Return type:	string
Raises:	`ValueError` – If any of the classnames in schema_classes are not in the DMTF CIM schema installed

clean()[source]¶

Remove all of the MOF files and the schema_mof_dir for the defined schema. This is useful because while the downloaded schema is a single compressed zip file, it creates several thousand MOF files that take up considerable space.

The next time the DMTFCIMSchema object for this schema_version and schema_root_dir is created, the MOF file are extracted again.

remove()[source]¶: The schema_mof_dir directory is removed if it esists and the schema_zip_file is removed if it exists. If the schema_root_dir is empty after these removals that directory is removed.

9. Mock support¶

9.1. Overview¶

9.2. Faked WBEM operations¶

9.2.1. Faked instance operations¶

9.2.2. Faked association operations¶

9.2.3. Faked method invocation operation¶

9.2.4. Callback functions for faked method invocation¶

9.2.5. Faked pull operations¶

9.2.6. Faked iter operations¶

9.2.7. Faked class operations¶

9.2.8. Faked qualifier operations¶

9.3. Building the mock repository¶

9.3.1. Example: Set up qualifier types and classes in DMTF CIM schema¶

9.3.2. Example: Set up qualifier types and classes from MOF¶

9.3.3. Example: Set up instances from single CIM objects¶

9.4. FakedWBEMConnection¶

9.5. DMTF CIM schema download support¶

Table Of Contents

Previous topic

Next topic

This Page