Share This:

This Pulse Blog provides information on how to utilise the OOB SRM Web Services to create an integration point for a third party system where Service Requests can be initiated externally, and parameters/values passed in from the third party system for use with branching and fulfilment requirements.


I was recently asked for information surrounding how to use these SRM Web Services, which was timely as I am currently using the Interface forms via BAO for an external third party integration to initiate Service Requests and pass through information to the underlying fulfilment requests at my current customer.


** One restriction with using the SRM Web Services is that you cannot utilise the Questions as defined on the SRD **


This then poses the question of how do I then pass in the required information from the third party integration if I cannot invoke the normal SRD Questions as defined in BMC SRM?


Answer:  We can utilise the Service Request SR Type Fields to store and pass the required information through to the PDT / fulfilment request for processing.


There are however some "gotchas" to look out for when using the interface forms such as the fact that BMC has not included/exposed all the possible Work Order Type Fields to SRM via the CAI.  There is a subset of field available, so we need to aware of this when using the SR Type Fields.  By default, the SR Type Fields are automatically mapped through to the equivalent Work Order Type Fields when using Work Order as the fulfilment but the restriction on what is mapped needs to be noted.


The following information is an extract from the following document:


Using BMC SRM OOB Web Services


Example working soapUI calls are attached to this Blog post - replace the values for authentication and LoginID's as required.


Interfacing Example – Create Service Request > Work Order creation using PDT variables and SR Type Fields


The following example shows how to use the SRM Web Service to create a Service Request passing in parameters (which can be question answers) to branch to the correct Work Order.  The parameters are passed through the interface into the SRM SR Type Fields on the “SRM:Request” form,  where they are then mapped into PDT variables (via the SRD configuration) for use with the processing and passing to the underlying fulfilment request.


NOTE:  For some unknown reason, not all the WO Type Fields are exposed from the SRM Forms when mapping through using the OOB workflow i.e. Work Order Type Fields 1-30 and 48-51 are the only exposed fields where a one to one mapping can be achieved from SRM > WO without the requirement to expose these in the SRM AOT.  If additional fields are required, then the associated interface forms customisation and CAI configuration is required.



** If using Work Order Management as fulfilment, SR Type Fields are automatically mapped to Work Order Type Fields where available on the WO **


1.  Create 2 Work Order Templates for use with the PDT (this will demonstrate the ability to "branch" on an incoming input value).


Integration Picture 1.png


2.  Create the AOT > Work Order Template Associations, and expose the required fields in the underlying fulfilment.


Integration Picture 2.png


3.  Create PDT, Variables and Conditioning.  In this example, SR Type Field 10 will provide the conditional parameter to the “var_Condition” PDT variable via the SRD Mappings.


Integration Picture 3.png


Integration Picture 4.png


4.  Create a SRD and map through SR Type Fields that will be used in the integration.  ** Any SR Type Field that has an equivalent Work Order Type Field will automatically be mapped through (see note above about exposed SRM > WO fields) and there is no need to expose in the AOT **


Note: As this is used purely for integration purpose, no questions have been defined on the SRD although you may utilise the one SRD for both internal and interface purposes if you map the SRD Question/Answers into the SR Type Fields as would be provided through the interface.


Integration Picture 5.png


Integration Picture 6.png


5.  Test the Web Service by passing in the required values. If successful, you will be returned the Service Request Number.  The associated fulfilment application request will also be created.


Integration Picture 7.png


Integration Picture 8.png


Integration Picture 9.png


Integration Picture 10.png


Sample soapUI call for Submit (Simple format):


<soapenv:Envelope xmlns:soapenv="" xmlns:urn="urn:SRM_RequestInterface_Create_WS">











         <urn:Short_Description>Test from soapUI</urn:Short_Description>


         <urn:SR_Type_Field_1>This is the Notes field</urn:SR_Type_Field_1>

         <urn:SR_Type_Field_2>Answer 1</urn:SR_Type_Field_2>

         <urn:SR_Type_Field_3>Answer 2</urn:SR_Type_Field_3>

         <urn:SR_Type_Field_4>Answer 3</urn:SR_Type_Field_4>

         <urn:SR_Type_Field_5>Answer 4</urn:SR_Type_Field_5>


         <urn:AppRequestSummary>SRM Interface Test</urn:AppRequestSummary>


         <urn:Source_Keyword>Interface Form</urn:Source_Keyword>

         <urn:SR_Type_Field_10>Template Two</urn:SR_Type_Field_10>


         <urn:Company>Calbro Services</urn:Company>


         <urn:Details>Testing from soapUI</urn:Details>











As can be seen above, the SR Type Fields have been used to pass in parameters to the Service Request which have then been used in the PDT to:


  • Branch to the correct Work Order (AOT) (SR Type Field 10 > PDT Condition evaluation)
  • Form part of the Summary for the fulfilment request (SR Type Field 10 = SRD Title + SR Type Field 10)
  • Map to the Notes field on the Work Order (SR Type Field 1)
  • Map to Work Order Type Fields (Work Order Type Fields 2 - 5) Note: This was done automatically by the system without the requirement to expose these fields in the AOT


I hope this takes some of the mystery out of using SRM Web Services and what can be achieved via integration to these Web Services.


Kind regards,

Carl Wilson