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