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.

<!-- CLIENT MIX -->

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

...

<consume name="myConsume"
  service="Subr"
  fields="myField1">
  <prop name="subr.spec"
    function="anyFun"
    Param1="myField1"/>
</consume>

<!--  SAMPLE USER MIX -->

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

...

<notify name="myNotify"
  service="Sequencer"
  clients="Subr"
  fields="myField1">
  <prop name="subr.spec"
    function="anyFun"
    Param1="myField1"/>
</notify>

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 and parameterising the fields.
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.
Note: 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.
Parameter
Parameter names have to be capitalised. The parameters specified in the caller operation has to be specified for the subroutine as well.
The type of the fields mapped to the same parameter has to be the same.
Tip: The subr.spec property can also contain Erlang extensions used as predicates.
...

<request name="Router1Version" 
  service="ISR" 
  fields="SOME_FIELD">  
  <prop name="subr.spec" 
    function="GetVersion" 
    ancestor="isr4453" 
    Version="router1_version"/>  
  <reply name="Ok" 
    fields="router1_version"/>
</request>   

...

<folder name="isr4453">    
  <solicit name="GetVersion" 
    service="Sequencer"
    clients="Subr"  
    fields="GET_VERSION ISR4453">    
    <prop name="subr.spec" 
      function="GetVersion" 
      Version="version"/>    
    <response name="Ok" 
      fields="version"/>  
  </solicit>

...
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>

...