SOAP response 137 to valid(?) request

[Anonymous]

I am interacting with Vault 2014 using the SOAP API and the FindItemRevisionsBySearchConditions operation.  Reading the WSDL, I believe that the following XML is valid:

<env:Envelope xmlns:lol0="http://AutodeskDM/Services/ItemService/1/20/2011/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header>
    <lol0:SecurityHeader>
      <lol0:Ticket>d57edeba-1919-40e3-b397-e4aec5fd8593</lol0:Ticket>
      <lol0:UserId>3</lol0:UserId>
    </lol0:SecurityHeader>
  </env:Header>
  <env:Body>
    <lol0:FindItemRevisionsBySearchConditions>
      <lol0:searchConditions>
        <lol0:SrchCond PropDefId="264" SrchOper="1" SrchTxt="7103-1201" PropTyp="AllProperties" SrchRule="Must"/>
        <lol0:SrchCond PropDefId="59" SrchOper="1" SrchTxt="Work" PropTyp="SingleProperty" SrchRule="Must"/>
      </lol0:searchConditions>
      <lol0:bRequestLatestOnly>true</lol0:bRequestLatestOnly>
    </lol0:FindItemRevisionsBySearchConditions>
  </env:Body>
</env:Envelope>

 However, I receive error 137 (illegal input params) whenever I have any SrchCond elements, although those elements look well formed to me.  Does anybody have any examples of a valid request, or is there something I'm missing in the request?

Thanks,

Louis

[paul.gunn]

Hi Louis,

I don't see any obvious problems here. I submitted this to one of our servers with Fiddler (with minor adjustments to ticket , etc ) and got a successful response. So it isn't immediately clear to me what the problem is.

You might want to double check your http headers, etc for correctness - or monitor successful calls from the Vault client app with a tool like Fiddler to see if there are differences vs. what your are doing.

Paul

[Anonymous]

Hi Paul,

Fiddler is a really cool tool, thanks for the heads up.  Is there somewhere you can see a proper XML request/response occur (i.e. from the Vault web client)?  I can see the get request occur, though I can't find any XML, but I might just be missing it.

My understanding of error 137 is that it should not be sent for a headers problem, but I guess it's possible.

[paul.gunn · Accepted solution]

Hi,

For both the request and response, there is an 'inspector' tab. I usually use the text view to examine the XML. The headers section is also quite useful. The 'composer' tab is the one I used to text the XML fragment you posted .

Paul

[Daniel.Du]

Yes, use fiddler, you will love it! 🙂

[Anonymous]

Fiddler does a great job at intercepting my browser traffic, but is there a way to capture other processes?  Our SOAP access is done via Ruby (and the Savon library), which Fiddler doesn't bind to.  May be a question better suited to Fiddler's forums.  I've seen some stuff about routing through a proxy, but it seems a bit convoluted.

Is there any documentation somewhere that would let me at least pin error 137 down to headers or message body?  If I remove the SrchCond elements, it returns the default search results, so I thought the error was in those elements, but they seem valid per the WSDL which paul.gunn's success seems to indicate.

Are there any server configuration options which could be related?

[paul.gunn]

Hi,

There aren't any general configuration settings that would affect the validity of the parameters. So it is a bit of a mystery why the same xml would work for me but not in your environment.

One thought - if you could post your server vlog with the error, the stack trace there might give some insight into where the error is being thrown.

Paul

[Anonymous]

The vlog follows.  It seems to be very similar to the SOAP response data.

10/11/2013 8:26:32 AM *******************************************************************
Error: Soap Exception ( mesg-id = 635170767926913657 )
Exception: IllegalInputParam [137] 
Stacktrace: 
Server stack trace: 
   at Connectivity.Core.Operations.SearchContext.GetSearchClause(SearchCondition sc, SearchTerm searchTerm)
   at Connectivity.Core.Operations.SearchContext.BuildQuery(SearchCondition sc)
   at Connectivity.Core.Operations.SearchQuery.Add(SearchCondition sc)
   at Connectivity.Core.Operations.Searching.ConstructSearchQuery(LuceneSearcher searcher)
   at Connectivity.Core.Operations.Searching.Execute(TermFilter filter, String& bookmark, SearchStatus& searchstatus)
   at Connectivity.Product.DataAccess.ItemProperties.FindItemRevisions(SearchCondition[] conditions, SortCondition[] sortConditions, Boolean latestOnly, String& bookmark, SearchStatus& searchstatus)
   at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Connectivity.Product.Services.ItemPropertyService.FindItemRevisionsByPropertySearchConditions(SearchCondition[] searchConditions, SortCondition[] sortConditions, Boolean bRequestLatestOnly, String& bookmark, SearchStatus& searchstatus)
   at Connectivity.Web.Services.v16.ItemService.FindItemRevisionsBySearchConditions(SearchCondition[] searchConditions, SortCondition[] sortConditions, Boolean bRequestLatestOnly, String& bookmark, SearchStatus& searchstatus)
   at SyncInvokeFindItemRevisionsBySearchConditions(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

10/11/2013 8:28:42 AM Begin executing event Autodesk.Events.Maintenance at 10/11/2013 8:28:42 AM
10/11/2013 8:28:42 AM End executing event Autodesk.Events.Maintenance at 10/11/2013 8:28:42 AM

[paul.gunn]

Hi,

Unfortunately the error log doesn't lend much insight. My best suggestion is to capture successful search requests (e.g. from vault client) in fiddler and determine differences between those and the requests you are sending - hopefully pointing to an explanation / solution.

Paul