Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    Walter Kamp
    Aug 17 Soap API APIAccessRequestHeader required
    Topic posted September 21, 2017 by Walter KampSilver Medal: 2,000+ Points 
    893 Views, 11 Comments
    Title:
    Aug 17 Soap API APIAccessRequestHeader required
    Content:

    We're working on a SOAP integration with OSC Aug '17 version and see that since this version we have to send an "APIAccessRequestHeader" as well. We can manage to get it working, but I tried to find information about this in the API documentation, but can't find anything about this new header we have to send.
    Anyone having some information about this new 'feature'?

    Thanks,
    Walter Kamp
    WeSquare

    Version:
    Service Cloud Aug 17

    Comment

     

    • P O'Neal

      I have ran into this as well. What are you passing for the token? I Really frustrating that there are no docs!

    • Mike Waldron

      Yeah, I just got blindsided by this too. Walter, what are you using for the token value?

      Oracle, can we get some official guidance on this point? A link to documentation would be great if we've all overlooked it. I'm kind of hung up on a project I'm working on until I get this ironed out.

    • Danette Beal

      Thanks for the feedback all!

      I've passed this post along to the documentation team.

      Regards,

      Danette, Community Manager

    • Nivedhitha Sundaramurthi

      Hi everyone,

      The documentation is being updated regarding this new header introduced in Aug'2017 release. In the meanwhile, please find some details below regarding the same -

      Starting Connect V1.4, all CWSS responses will return a custom header "APIAccessResponseHeader" shown as follows :

      <soapenv:Header>
          <n0:APIAccessResponseHeader xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:n0='urn:messages.ws.rightnow.com/v1_4'>
            <n0:Token>EYJHBGCIOIJIUZI1NIJTRHNDETYMVKZS0WYJM0M2Z</n0:Token>
            <n0:NextRequestAfter>0</n0:NextRequestAfter>
          </n0:APIAccessResponseHeader>
        </soapenv:Header>

      The Token identifies the current or existing connection to optimize QoS connection among other competing connections and needs to be provided in the subsequent API request. The NextRequestAfter indicates the time (in milliseconds) that should elapse before you make the next request.

      Similarly, there is a custom header introduced in the request "APIAccessRequestHeader" that will hold the token element.

       <n0: APIAccessRequestHeader>
              <no:Token>EYJHBGCIOIJIUZI1NIJTRHNDETYMVKZS0WYJM0M2Z</n0:Token>
         </n0: APIAccessRequestHeader>

      This is an optional custom header but omitting it may lead to degraded performance and errors, even if it seems to test well without it. As mentioned above, the token value received in the response header should be passed in the subsequent request header. Please do not tamper with the token value. Any change in the token value will result in an error.

      Hope this helps.

      Thanks!

    • Mike Waldron
      1. When C# bindings are generated from the WSDL, the APIAccessRequestHeader isn't optional - it's mandatory
      2. Because of that, I can't send a request
      3. Because of that, I can't get a response
      4. So I don't have the opportunity to get a token value for the next request.

      What do I do for my initial request? I'm sorry, but this explanation doesn't make sense.

    • Walter Kamp

      I assume it's related to the REST access token: http://docs.oracle.com/cloud/latest/servicecs_gs/CXSVC/c_Authentication_aa1151642.html#aa1152221

      But we couldn't get it working that way... a more simple solution was passing this:
      new APIAccessRequestHeader() { Token = "" }
      So, simply using an empty Token works for us.

    • Mike Waldron

      Thank you Walter, that worked for me. I can't believe I didn't try that sooner.

      This QoS thing is strange - as far as I know neither I nor my endusers care about it. It sounds data-centerish, and my add-ins/utilities never send requests fast enough to worry about waiting some number of milliseconds between calls, so I think I'm just going to use blank APIAccessRequestHeaders from now on. Maybe if the first one is blank, then you get a real token value to use with the next request.

    • Ammar Aldaffaie

      I'm running into the same problem now after the upgrade and while I'm trying to create a new add-in. A documentation or a simple example will be great 

    • Mike Waldron
      Ammar Aldaffaie said:

      I'm running into the same problem now after the upgrade and while I'm trying to create a new add-in. A documentation or a simple example will be great 

      View original

      When I need an APIAccessRequestHeader, I just do this, Ammar:

                 var aarh = new APIAccessRequestHeader() { Token = "" };
      

      I don't worry about the QoS business or sending the last token value back or any of that jazz.

    • Ammar Aldaffaie

      Thank you so much, Mike, that did work for me!