Partager via

Envoyer et recevoir des pages ASPX

  • Article

Les pages ASPX de Microsoft BizTalk Accelerator for RosettaNet (BTARN) sont les interfaces directes entre BTARN et Internet. Les deux pages ASPX sont la page de réception (RNIFReceive.aspx) et la page d’envoi (RNIFSend.aspx). Chaque page ASPX est une extension du pipeline BTARN correspondant. Le pipeline nécessite la page ASPX pour gérer les en-têtes RosettaNet Implementation Framework (RNIF). Le pipeline effectue la majeure partie du traitement HTTP ; Toutefois, chaque page ASPX effectue le traitement HTTP des en-têtes RNIF. Les pages augmentent les fonctionnalités de l’adaptateur HTTP BizTalk Server.

Chaque page ASPX est une application web ASP.NET sans interface utilisateur. Ils utilisent ASP.NET sécurité web pour garantir une connexion sécurisée avec des parties externes. Ils fournissent une couche dans laquelle vous pouvez implémenter la tolérance de panne, la scalabilité et les services hautement disponibles.

Le programme d’installation de BTARN installe une page RNIFSend.aspx et une page RNIFReceive.aspx sur chaque déploiement de BTARN. Lorsque l’initiateur ou le répondeur échange des messages avec le partenaire commercial, BTARN utilise les pages ASPX pour envoyer des messages à l’URL du partenaire ou en recevoir des messages. Si l’initiateur et le répondeur utilisent BTARN, les deux pages ASPX de l’initiateur échangent des messages avec les deux pages ASPX du répondeur. Pour plus d’informations, consultez la sous-section « Interaction des pages ASPX de l’initiateur et du répondeur » ci-dessous.

Envoyer la page ASPX

La page RNIFSend.aspx reçoit un message de l’adaptateur HTTP BizTalk. Il crée et ajoute des en-têtes RNIF au message, puis envoie le message au partenaire via Internet. L’adaptateur HTTP appelle RNIFSend.aspx avec la commande suivante :

http://localhost:<port number>/RNIFSend.aspx?<query string>

La chaîne de requête inclut les données suivantes dont la page d’envoi a besoin pour envoyer le message au partenaire, ainsi que les données dont le partenaire doit disposer pour traiter le message :

  • URL du partenaire commercial : http://www.<address.com>/RNIFReceive.aspx

  • Type de réponse : sync ou async

  • Version RNIF : 1.1 ou 2.0.

    L’adaptateur HTTP BizTalk envoie un message MIME produit par le pipeline d’envoi BTARN à la page RNIFSend.aspx de l’initiateur. RNIFSend.aspx traite le message comme suit :

  1. La page d’envoi effectue la validation sur le message.

  2. La page d’envoi crée un en-tête MIME (Multipurpose Internet Mail Extensions) en fonction du type de contenu, de la longueur, de l’ID et de la version MIME. Il ajoute l’en-tête MIME et les limites MIME supérieures et inférieures au message.

  3. Pour RNIF 2.01, la page d’envoi définit les propriétés de l’en-tête HTTP comme suit :

    1. Elle définit la propriété X-RN-Version sur la version entrée dans la propriété Version des paramètres de configuration du processus.

    2. Il définit la propriété X-RN-ResponseType sur sync ou async, en fonction du paramètre de la propriété IsSynchronous dans les paramètres de configuration du processus.

    3. Il définit la propriété Content-Length sur la taille du message complet.

  4. À l’aide d’une publication HTTP, la page d’envoi envoie le message à l’URL de destination du partenaire, comme défini dans les paramètres URL d’action ou URL de signal dans le contrat de partenaire commercial.

  5. La page d’envoi attend la réponse HTTP. Lorsqu’il reçoit la réponse, il l’achemine vers l’adaptateur HTTP.

  6. Si la connexion est asynchrone, la page d’envoi ferme la connexion et son traitement est terminé.

  7. Si la connexion est synchrone, la page d’envoi conserve la connexion ouverte pour un message retourné. Une fois le message reçu, il effectue le même traitement qu’une page RNIFReceive.aspx sur un message reçu, envoie le message reçu à l’adaptateur HTTP, puis ferme la connexion.

Page ASPX de réception

La page RNIFReceive.aspx reçoit un message HTTP du partenaire sur Internet. Il traite, valide, puis supprime les en-têtes RNIF et envoie le message à l’adaptateur HTTP. Le message reçu par la page de réception doit être conforme au transport HTTP RNIF. La page de réception traite les messages comme suit :

  1. La page RNIFReceive.aspx du répondeur reçoit le message de l’initiateur. Le message contient l’en-tête MIME et les limites supérieures et inférieures.

  2. La page de réception valide l’en-tête MIME.

  3. La page de réception supprime l’en-tête MIME et les limites du message.

  4. La page de réception publie le message sur l’adaptateur HTTP à l’aide de l’emplacement de réception HTTP. La page de réception reçoit une réponse HTTP et retourne la réponse HTTP à la page d’envoi de l’initiateur.

  5. Si la connexion est asynchrone, la page de réception ferme la connexion.

  6. Si la connexion est synchrone, la page de réception maintient la connexion ouverte, en attendant qu’un message soit retourné.

  7. Une fois qu’elle a reçu le message retourné de l’adaptateur HTTP, la page de réception effectue le même traitement qu’une page RNIFSend.aspx et envoie le message retourné à la page d’envoi de l’initiateur. Une fois qu’il a reçu la réponse HTTP, il ferme la connexion.

Interaction des pages ASPX de l’initiateur et du répondeur

Si l’initiateur et le répondeur utilisent BTARN, les quatre pages ASPX sur l’initiateur et le répondeur interagissent différemment selon que les connexions sont asynchrones ou synchrones, et que les messages sont à action unique ou double action. Les sous-sections suivantes décrivent l’ensemble complet des interactions.

Asynchrone à double action

Ce scénario implique quatre connexions HTTP distinctes, une pour chaque étape :

  1. La page d’envoi de l’initiateur envoie le message de demande d’action à la page de réception du répondeur.

    Notes

    Les étapes 2 et 3 ci-dessous peuvent se produire dans l’ordre inverse, en fonction de la charge du système.

  2. La page d’envoi du répondeur envoie un message de signal de demande à la page de réception de l’initiateur.

  3. La page d’envoi du répondeur envoie un message de réponse d’action à la page de réception de l’initiateur.

  4. La page d’envoi de l’initiateur envoie un message de signal de réponse à la page de réception du répondeur.

    Asynchrone à action unique

    Ce scénario implique deux connexions HTTP distinctes, une pour chaque étape. Notez que ce scénario se compose des étapes 1 et 2 du scénario asynchrone à double action.

  5. La page d’envoi de l’initiateur envoie le message de demande d’action à la page de réception du répondeur.

  6. La page d’envoi du répondeur envoie un message de signal de demande à la page de réception de l’initiateur.

    Double action synchrone

    Ce scénario implique une connexion HTTP :

  7. La page d’envoi de l’initiateur envoie le message de demande d’action à la page de réception du répondeur.

  8. La page de réception du répondeur envoie un message de réponse d’action (ou une exception, en cas de problème) à la page d’envoi de l’initiateur sur la même connexion que celle utilisée à l’étape 1.

    Synchrone à action unique

    Ce scénario implique une connexion HTTP :

  9. La page d’envoi de l’initiateur envoie le message de demande d’action à la page de réception du répondeur.

  10. La page de réception du répondeur envoie un message de signal de demande (ou une exception, en cas de problème) à la page d’envoi de l’initiateur sur la même connexion.

Voir aussi

Traitement de messages dans BTARN
Pipeline de réception BTARN
Pipeline d’envoi BTARN