Hi Bruno S,

Adding to the previous answer, DataMiner Profiles come in very handy as a means to bundle multiple parameters together in a single set. As an example, DataMiner Service and Resource Manager (SRM) uses profiles to orchestrate full configurations on functions. E.g. assume you have an encoder that needs to be orchestrated by DataMiner, you may create a profile containing multiple configuration parameters such as:

{

video=H.264

Resolution = High_Definition

Bitrate = 5 Mbps

StreamingOutput=ON

RequiredCPUCores = 4

}

As you can expect, applying multiple configuration parameters on products, is not just a series of commands that are executed one by one, meaning parameter by parameter. First of all, the likelyhood that products expose API’s where each parameter can be individually set is shrinking down (moving from SNMP to RESTful). Secondly, parameters may need to be set in a well defined order – even using SNMP that is the case (think of it like a transactional behavior). … and that order will be different from technology vendor to technology vendor. So that’s why in DataMiner SRM, one can attach ‘ProfileLoadScripts’ to certain functions. Those ProfileLoadScripts execute on the entire transaction, and can be tuned to the specific technology.

So in short, profiles:

• contain parameters you can use to mediate across technology
• this group of parameters can be linked to an SRM ProfileLoadScript and therefore contain ‘transactional’ behavior that can also be tuned to the specific underlying technology

There’s much more to it, a single profile may have variations (state profiles, e.g. a stop profile would just contain the ‘overly’ on the profile saying StreamingOutput = OFF), and also contain requirements to underlying resources in terms of the capacity and capability needs. DataMiner SRM would then use those requirements to find a suitable encoder having 4 CPU cores available using the example above.

HTH, Steven