Verified in SDM 14.1 and 17.1. Multi-tenanted. Conventional architecture.
There is a support ticket open on this to check for a product defect but we need to verify our code and possible workarounds.
I have never seen this behavior and since we can reproduce it all environments on both versions, I hope someone else has seen it.
Steps to reproduce:
1. Create ticket in SDM using the createRequest() method.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://www.ca.com/UnicenterServicePlus/ServiceDesk"> <soapenv:Header/> <soapenv:Body> <ser:createRequest> <sid>132554172</sid> <creatorHandle></creatorHandle> <attrVals> <!--1 or more repetitions:--> <string>impact</string> <string>1</string> <string>tenant.name</string> <string>MyTenant</string>string> <string>affected_resource.name</string> <string>WIN10_12345</string> <string>customer</string> <string>U'13CB8A455B0E3841B89FC60F707D5989'</string> <string>category</string> <string>pcat:5103</string> <string>summary</string> <string>This is CI test 1</string> <string>description</string> <string>What is up with these CIs?</string></attrVals> <propertyValues> <!--1 or more repetitions:--><string></string> </propertyValues> <template></template> <attributes> <!--1 or more repetitions:--> <string>ref_num</string> </attributes> <newRequestHandle>?</newRequestHandle> <newRequestNumber>?</newRequestNumber> </ser:createRequest> </soapenv:Body></soapenv:Envelope>
2. Verify the ticket is created with CI by opening in GUI.
3. Verify that the CI is NOT in the affected_rc field for the record in the MDB. (Note: If you have made the CI field visible in your search results / list form, the CI will not be displayed here either).
4. Change to Edit mode. Save the ticket without making any changes.
--> The CI is now saved to the MDB and visible in the list form.
5. Create a new Request via the GUI.
---> The CI field is populated with the same CI you used to create the first ticket via SOAP. This is before you enter any information in the ticket and regardless of the tenant relationship to the CI.
--> Remove the CI, complete the ticket, and save it. The CI is still displayed in the view mode.
6. Open ANY existing ticket, active or inactive, that didn't have a CI and the same CI from the SOAP is displayed.
This behavior can be cleared by creating another request via SOAP, but send an empty string for the affected_resource.name
We have tried using just affected_resource (without .name) with the CI's UUID, but it has no effect.
Hi J.W.To my experience, you always have to specify the persistent_id as the value of a so called SREL attribute. As you did for the category field. Something like "... .name" to use the common name of a referenced object will not work, as far as I am aware. Same is for customer and affected_resource . Values should look like "cnt:..." and "nr:..."I am unsure regarding the tenant field. I would ommit this one.should be set automatically by the system, same way as in the GUI.Hope that helpsBest regards....Michael
The issue is that despite appearances, createRequest does not accept dotted notation in attrVals. I was coding from my examples before the docs for 14.1 and 17.1 were updated. Never assume.
We don't have to send the persistent_id, but can send just the UUID enclosed with the U'xxxxx' notation as in the customer example above.
This completely resolves the issue.