Api La direction fixe l'avant demande d'une demande d'une façon

Question

Je veux vous connecter pour enregistrer la demande et la réponse si je place un sens unique de demande dans l'arrivée et la section sortante:

<policies> 
    <inbound>      
     <send-one-way-request mode="new"> 
      <set-url>@("example.com")</set-url> 
      <set-method>POST</set-method>    
      <set-header name="Content-Type" exists-action="override"> 
       <value>application/json</value> 
      </set-header> 
      <set-body>@(context.Request.Body.As<string>(preserveContent: true))</set-body> 
     </send-one-way-request> 
    </inbound> 
    <backend> 
     <base /> 
    </backend> 
    <outbound>   
     <send-one-way-request mode="new"> 
      <set-url>@("example.com")</set-url> 
      <set-method>POST</set-method>    
      <set-header name="Content-Type" exists-action="override"> 
       <value>application/json</value> 
      </set-header> 
      <set-body>@(context.Response.Body.As<string>(preserveContent: true))</set-body> 
     </send-one-way-request> 
    </outbound> 
</policies> 

identiques appeler, sauf le corps.

Quand je vérifie la trace que je vois cela dans la section d'arrivée:

envoi-one-way-demande (0 ms)

"One way request was successfully send to https://...." 

avant-demande (9690 ms)

{ 
    "response": { 
     "status": { 
      "code": 200, 
      "reason": "OK" 
     }, 
     "headers": [ 
      { 
       "name": "Pragma", 
       "value": "no-cache" 
      }, 
      { 
       "name": "Content-Length", 
       "value": "2" 
      }, 
      { 
       "name": "Cache-Control", 
       "value": "no-cache" 
      }, 
      { 
       "name": "Content-Type", 
       "value": "application/json; charset=utf-8" 
      }, 
      { 
       "name": "Date", 
       "value": "Wed, 05 Jul 2017 07:56:14 GMT" 
      }, 
      { 
       "name": "Expires", 
       "value": "-1" 
      }, 
      { 
       "name": "Server", 
       "value": "Microsoft-IIS/8.0" 
      }, 
      { 
       "name": "X-AspNet-Version", 
       "value": "4.0.30319" 
      }, 
      { 
       "name": "X-Powered-By", 
       "value": "ASP.NET" 
      } 
     ] 
    } 
} 

mais dans le sortant, je ne reçois que:

envoi-one-way-demande (0 ms)

"One way request was successfully send to https://...." 

et aucune demande de transfert. Comme j'utilise une requête unidirectionnelle, je ne m'attends pas à une réponse des appels et je ne peux pas me souvenir d'avoir le forward-request dans la partie entrante (je ne les ai pas trouvés dans un appel tracée enregistré avec une demande unidirectionnelle dans l'appel entrant).

Y at-il peut-être une configuration autre chose qui déclenche une demande de transfert?

Edit:

utiliser la fonction d'azur pour gérer cela. Quand je fais une faute de frappe dans le sous-domaine, la requête forward disparaît, mais quand je fais une faute de frappe dans le nom de la fonction, elle est toujours là ... Les deux requêtes sont dirigées vers la même fonction azure.

Edit2:

Cela devient plus confuse: quand j'envoie le corps par défaut du fichier fanfaronnades la demande vers l'avant est pas là. Si je répète la demande ou si je modifie le corps par défaut, il apparaît ...

Answer 1

Étant donné que la politique de demande d'envoi unilatéral est complètement asynchrone en ce qui concerne le traitement des demandes lui-même, il n'y a aucune garantie que la réponse de cette requête sera connecté, car au moment où il est reçu la demande elle-même peut être traitée depuis longtemps, la réponse retournée au client avec des informations de suivi. Donc, cela fonctionne comme un meilleur effort, si au moment où la réponse à la demande d'envoi-un-chemin est reçue, la demande principale est toujours en cours de traitement, la réponse sera enregistrée, sinon non.

Dans le premier exemple, la réponse à la demande unidirectionnelle en entrée est enregistrée car il y a encore beaucoup de traitement à effectuer sur la demande principale - envoyer la demande au backend, traiter la section sortante. Mais lorsqu'une requête unidirectionnelle est placée comme dernière instruction en sortie, juste avant l'envoi de la réponse au client, la réponse à une demande unilatérale viendra trop tard pour être placée dans la trace.

Une faute de frappe dans le sous-domaine peut déclencher une durée de connexion plus longue, si ce domaine ne refuse pas activement les connexions, il bloquera ainsi la réponse, il disparaîtra ainsi de la trace.

Tout est une question de timing. Si vous voulez vous assurer que le traitement de la requête principale est bloqué jusqu'à ce que vous obteniez une réponse de ces demandes secondaires, utilisez plutôt la politique de demande d'envoi.