Using the Subroutine extension

See here the markup to use svc_subr in a mix.

Markup

See Table 1 and Table 2 on the properties.

<folder name="Sample">
  
  <mix name="Client">
    <service name="Subr" provision="subr">
      <prop name="subr.import" 
        key="some_key" 
        user="sample@domain.com" />
    </service>

    <consume name="myConsume"
      fields="master1" 
      service="Subr">
      <prop name="subr.spec" 
        function="anyFun"/>
      <prop name="params"><![CDATA[
param1:master1
      ]]></prop>
    </consume>
  </mix>


  <mix name="User">
    <service name="Subr" provision="subr">
      <prop name="subr.export" key="some_key"/>
    </service>

    <notify name="myNotify" 
      clients="Subr" 
      fields="slave1" 
      service="Sequencer">
      <prop name="subr.spec" 
        function="anyFun"/>
      <prop name="params"><![CDATA[
param1:slave1
      ]]></prop>
    </notify>
  </mix>
</folder>

Properties

Table 1. Subroutine expression - Operation properties
Property Description Example
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.
Important: 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.

The following attributes define a match:

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".
ancestor
An optional attribute that can be used to specify a folder, to consider only those operations that are inside the given folder.
Tip: Since a mix counts as a folder, it can also be used as a value for the ancestor attribute.

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.
 
<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>
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. For example: param1:field1 param2:field2.

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

Important: If the parameterised fields are not of the same type, the value is cast using the sse_type_util:coerece/2 function.
 
<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>
Table 2. svc_subr - Service properties
Property Description Example
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.
Important: A user can only import another user's SPARKL resources if he has execute rights.
user
Specifies a user from whose account the service is imported.
key
Establishes a static configuration-based mapping between two or more services.
See also subr.export.		 
<service name="ISR" 
	provision="subr">  
    <prop name="subr.import" 
      user="ios@cisco.com" 
      key="v3.2"/>
 </service>
subr.export Use this property to offer a service, and the operations on it as subroutines, for other users.
Important: A user can only import another user's SPARKL resources if he has execute rights.
Tip: The subr.export property can be used on any service, not just those provisioned using svc_subr.
The export is done using the following:
key
Establishes a static configuration-based mapping between two or more services.
See also subr.import.
 
<service name="Subr3.2" 
  provision="subr">  
  <prop name="subr.export" 
    key="v3.2"/>
</service>