At the end of a service delivery, I have a need to submit a different service request, copying across some field values etc.
Sounds like using the API is only way, and I need to first call the getServiceDefinition to get service definition info such as version etc., and then call submitRequisition to submit the request.
Has anyone done this before as part of a delivery plan of a service, and can you share what approach you took and any system/technical challenges? Do all within Service Link? Or have an external automation tool submit the new request?
Any plans for product team to add some built in function to have a task to submit a new request?
You can use RAPI (Requisition API) for this, i am sure you are referring the same. We tried earlier with external tool (CPO) and Cisco API for that.
I did go ahead and was able to use tasks with service link to submit a separate request using RAPI much like you would do against an external system. Only thing is this interface or integration is specific to a particular service, so not very flexible in that you have to create separate SL agent and transformation etc. per each service you may want to request in this fashion.
Bundle feature will not work for us (and I think that feature has its own set of challenges) as the secondary request needs to be kicked off at the end of the first request depending on some conditions in my use case. (or maybe bundle can do that but when I looked in to it, it did not have much functionality/flexibility in terms of business logic/decisions).
I believe that this can be achieved via WebService as well. The 'RequisitionService' WSDL is having a function to submit a new request.
As of now I have 2 problems
1. You can get the version details from getServiceDefinition API from same WSDL (RequisitionService). You have to parse the XML to get it.
2. If I understand it correctly, we passed the credentials in auth headers from PO webservice call. I have to check it again.
Are you passing in the login/authentication information in the header section within the message body like kbasavar mentioned?
Will look something like this:
Keep in mind that the password needs to be encrypted string that you can use http://<yourserver>/RequestCenter/EncryptedPassword.jsp to generate.
Also, note that if Directory Integration is enabled, you would have to use the directory enabled/linked account password above. This is only for RAPI / RequisitionService API, and not Service Link Task API. For that, I came to learn that even if Directory Integration is enabled, you have to use the local password that is defined in the Person record, as it seems Directory Integration is only for Request Center, and not Service Link. I guess that has its pluses and minuses...
I have tested the AuthenticationService API by providing my credentials and it was working fine by populating a part of my details in the person document as the response.
So, I have provided my credentials as it is in the RequisitionService API which didn't work. The link which you have shared to me to generate the encrypted password didn't return any value. So, I will be checking with Cisco TAC Support for this as I am working with them already for the below response which I am getting though the directory integration is ON.
I thought that I need to use this WebService in a ServiceLink agent. Since you have mentioned this as an API, I am assuming that I dont need to have a WSListener for a response using the RequisitionService API. Am I correct?
The response error message I am getting while accessing the WS using SoapUI tool:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<faultstring>The user name header is invalid. It is either not present or empty!. Please send a valid header.</faultstring>
<errorMessage>The user name header is invalid. It is either not present or empty!. Please send a valid header.</errorMessage>
Regarding the encrypted password generation, make sure you put in the correct port if needed as well as http or https depending on your setup. Also, make sure you log in first, and then hit that link, as it appears if you get the login prompt when opening that URL, it does not correctly forward you to the requested URL after you log in. Also, that URL I believe can only be viewed by login with Site Administrator permissions/role.
The error you pasted seems to indicate that the authentication header is not correctly formatted. Double check that you are including the header information in the message body (i.e. XML) itself and the XML namespaces you are using are valid. Again, the header should look something like below:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:req="http://requisition.api.newscale.com">
Encrypted password should be for the directory integrated (i.e. Active Directory if using AD) account password if you have Directory Integration enabled. Also, the account being used needs to have proper API related roles/permissions I believe. This login/password in the header definition is not necessarily the Initiator or Customer of the requisition you are submitting -- those you define again within the message Body.
Lim, Thanks for the hint. The 'EncryptedPassword' link worked with the https protocol, where I mistakenly mentioned it with http. But, I am getting the same error in authentication though the header which you have mentioned is same as what available for me. Since I am using the SoapUI tool, it loads the request SOAP message automatically with appropriate namespace and header information.
I have also opened a case with Cisco TAC to find where the issue is.
This discussion is being added with more new questions One of my clarification is - If the encryptedpassword URL is restricted for the people who have the site admin role (I have this role enabled for me), how the performers of a queue will access it to mention the encrypted password to call this API to perform action on the task assigned to them? So, I believe this should be accessible for everyone.