This content has been marked as final. Show 23 replies
Please find the details below.
Web Content URL for SOAPUI checkin:
Web Content URL for UCM Web UI checkin:
And both the file & SOAPUI on same machine and UCM server running on different machine.
Edited by: lkakarla on Aug 17, 2012 4:39 PM
Attachment as in why do you need to do that ?This is other method of two available methods to work with files inside SOAP request. http://www.soapui.org/SOAP-and-WSDL/adding-headers-and-attachments.html#2-3-anonymous-attachments (2. Attachments and Inline Files).
For me, this method was most reliable and controllable one.
Since nothing that works for others work for you, I suggest another approach. You could try Inline file method (slightly different than so far trials).
Inside RequestProperties set Enable Inline Files to true and check that Enable MTOM is false.
Use this bare minimum request:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:chec="http://www.stellent.com/CheckIn/">
<chec:dDocTitle>Test wsdl checkin</chec:dDocTitle>
Major difference is *<chec:fileContent>file:<path to the file></chec:fileContent>*
I must say that method with declaring path to the file inside fileName element:
never worked for me, but the one I'm proposing works.
I can see the same issue happening on my 18.104.22.168.0 instance with Soap Requests.
If you see carefully the file that is checked in through SOAP does not have any file extension , where as ideally it should have had one like the one for web ui check-in .
Need to check this further .
You are certainly right and it does. On execution, SoapUI replaces referenced file name with encoded content, what can be confirmed by inspecting RAW request.
Both methods (attached or inline file) as I propose them, work flawlessly for me with any Content server version (10g or 11g including 22.214.171.124.0). However, method with declaring path to the file inside fileName element doesn't look right to me.