svc_subr properties

The Subroutine extension lets you call slave transactions masked as a single operation in the master transaction.

subr.export

Use this property to offer a service, and the operations on it as subroutines, for other users. The subr.export property can be used on any service, not just those provisioned using svc_subr.

<service name="Subr3.2" 
  provision="subr">  
  <prop name="subr.export" 
    key="v3.2"/>
</service>
Important: A user can only import another user's SPARKL resources if he has execute rights.

key

Establishes a static configuration-based mapping between two or more services.

subr.import

Use this property to import a service, and the operations on the service, from a different configuration tree. The import is done using the user and key attributes.

<service name="ISR" 
	provision="subr">  
    <prop name="subr.import" 
      user="ios@cisco.com" 
      key="v3.2"/>
 </service>
Important: A user can only import another user's SPARKL resources if he has execute rights.

key

Establishes a static configuration-based mapping between two or more services.

user

Specifies a user from whose account the service is imported.

subr.spec

Use this property to match a request or consume to a solicit or notify subroutine. The matching is done by specifying the same function for the operations. In the case of a solicit-request or solicit-consume/reply pairing, the number and name of the responses have to match the number and name of the replies.

<folder name="SubrFilters">
  <service name="Subr" provision="subr" />
  <mix name="Master">
    <field name="master" type="string"/>
    <consume name="Master"
      fields="master" 
      service="Subr">
      <prop name="subr.spec" 
        function="SubrFun"/>
    </consume>
  </mix>
  <mix name="Slave1">
    <field name="slave1" type="string"/>
    <notify name="Slave1" 
      clients="Subr" 
      fields="slave1"  
      service="Sequencer">
      <prop name="params"><![CDATA[
master:slave1
      ]]></prop>
      <prop name="subr.spec" 
        function="SubrFun"><![CDATA[
get("master") == "foo".
      ]]></prop>
    </notify>
  </mix>
  <mix name="Slave2">
    <field name="slave2" type="string"/>
    <notify name="Slave2" 
      clients="Subr" 
      fields="slave2" 
      service="Sequencer">
      <prop name="params"><![CDATA[
master:slave2
      ]]></prop>
      <prop name="subr.spec" 
        function="SubrFun"><![CDATA[
get("master") == "bar".
      ]]></prop>
    </notify>
  </mix>
  <mix name="Slave3">
    <field name="slave3" type="string"/>
    <notify name="Slave3" 
      clients="Subr" 
      fields="slave3"  
      service="Sequencer">
      <prop name="params"><![CDATA[
master:slave3
      ]]></prop>
      <prop name="subr.spec"
        function="SubrFun"/>
    </notify>
  </mix>
</folder>

To carry the field values too, you must either:

  • Use fields with the same name
  • Use the params property to map the fields to a parameter
Tip: The subr.spec property can also contain Erlang expressions used as predicates to conditionalize the firing of subroutines.

function

The matching operations have to specify the same function. If the function attribute is not defined, the default value is used, which is the name of the operation. For example, function="Consume1". If the function attribute is not defined, the default value is used, which is the name of the operation. For example, function="Consume1".

ancestor

An optional attribute that can be used to specify a folder, to consider only those operations that are inside the given folder. Since a mix counts as a folder, it can also be used as a value for the ancestor attribute.

params

Use this property to map input and output fields to parameters. Declare the mappings on the element level - separately for a request and a reply - as a space-separated list of parameter and field names.

<folder name="Routers">
  <request name="Router1Version" 
    fields="SOME_FIELD"  
    service="Subr">  
    <prop name="subr.spec" 
      ancestor="isr4453" 
      function="GetVersion"/>  
    <reply name="Ok"
      fields="router1_version">
      <prop name="params"><![CDATA[
version:router1_version
      ]]></prop>
    </reply>
  </request>
                  
  <folder name="isr4453">    
    <solicit name="GetVersion"
      clients="Subr" 
      fields="GET_VERSION ISR4453"  
      service="Sequencer">      
      <response name="Ok" 
        fields="version"/>  
    </solicit>
  </folder>
</folder>

If params is not specified, the field names are used by default.