Comme dit dans le précédent article (http://www.braincastconsulting.fr/azure-biztalk-services-integration-with-a-partner/) nous allons voir ici comment interagir avec le service Azure Biztalk que nous avons configuré.
Voici les sujets où nous allons mettre des points d’attention
- Requête HTTP
- L’ envoi des messages
- Mécanisme d’envoi des messages entre l’entreprise Y et l’entreprise Z
- Monitoring
- Visualisation des requêtes avec le protocole AS2
- Différence des abonnements
- Propriétés du header
- Déclaration de propriété supplémentaire dans le header de la requête
Requête HTTP
Si nous reprenons notre cas d’utilisation, l’entreprise Y a besoin d’envoyer un message à l’entreprise Z grâce à un accord préalablement créé.
La question à se poser maintenant est de savoir comment émettre des requêtes sur notre Azure Biztalk Services. La réponse est assez simple car nous pouvons trouver sur la MSDN plusieurs exemples de bases permettant de mettre en œuvre notre cas d’utilisation, mais avant de les mettre en pratique il nous faudra aussi comprendre l’ensemble du mécanisme qui doit être utilisé une fois la requête émise.
Comment ça fonctionne ?
Au travers de ce schéma, nous pouvons observer et comprendre le mécanisme suivant :
- L’entreprise Y va fournir les données d’authentification à l’ACS. Ici on parle d’un utilisateur déjà créé lors de la mise en place du service.
- Un jeton de sécurité nous sera remis après validation des données d’authentification.
- Une requête peut être émise contre le notre Biztalk Services grâce au token récupéré.
- La requête est transmise au Bridge source concerné par l’accord ciblé
- Délégation au Bridge de destination.
- Traitement des données par le web service de l’entreprise Z.
Pour résumer nous avons besoin d’une requête pour obtenir notre jeton de sécurité qui sera utilisé dans une autre requête pour envoyer nos données au Biztalk services.
Une fois que nous avons mémorisé le fonctionnement attendu nous pouvons dès lors écrire le code permettant la mise en place de la communication entre nos entreprises.
Reprenons les points du schéma afin de les faire correspondre à notre code source :
- Requête à l’ACS
- Récupération de la réponse de l’ACS
var runtimeToken = GetAcsToken();
- Requête sur le service Azure Biztalk
private static string SendMessageToBridge(string address, byte[] messageBytes, string token, string contentType, string sourceFile) { ServicePointManager.ServerCertificateValidationCallback = delegate(object s, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; }; string response; using (var webClient = new HttpRequestWebClient()) { webClient.Headers[HttpRequestHeader.Authorization] = string.Format(WrapProtocolConstants.WrapTokenForHeader, HttpUtility.UrlDecode(token)); webClient.Headers["AS2-To"] = "EntrepriseZ_AS2_ID"; webClient.Headers["AS2-From"] = "EntrepriseY_AS2_ID"; webClient.Headers["Message-ID"] = string.Format("<{0}>", string.Format("{0}@mycompany.com", DateTime.Now)); webClient.Headers[HttpRequestHeader.ContentType] = contentType; webClient.Headers["FileName"] = "AS2_" + sourceFile; byte[] uploadData = webClient.UploadData(address, "POST", messageBytes); LogTrackingId(webClient.ResponseHeaders); response = Encoding.UTF8.GetString(uploadData); } return response; } - Affichage de l’accord utilisé pour l’utilisation des bridges
- Tracking des messages AS2
- Traitement des données & accusé de réception par l’entreprise Z
En s’appuyant sur la dernière capture d’écran, nous observons que la propriété MDN ACK possède la valeur « Accepted ». Cela veut dire que l’entreprise Z a bien réceptionné les données de l’entreprise Y. (Attention : cela ne veut par dire que les données transmises sont au format attendues, il reste à votre charge de vérifier ce point si l’entreprise qui réceptionne vos données n’en contrôle pas l’intégrité).
public static string GetAcsToken()
{
using (var client = new WebClient())
{
client.BaseAddress = "https://mycompany1234-bts.accesscontrol.windows.net";
byte[] responseBytes = client.UploadValues(
"WRAPv0.9",
"POST",
new NameValueCollection {
{"wrap_name", "owner"},
{"wrap_password", "*******"},
{"wrap_scope", "https://mycompany.biztalk.windows.net"},
{"wrap_assertion_format", "SWT"}
});
string response = Encoding.UTF8.GetString(responseBytes);
return response
.Split('&')
.Single(value => value.StartsWith(WrapProtocolConstants.WrapAccessTokenFormat, StringComparison.OrdinalIgnoreCase))
.Split('=')[1];
}
}
Les points 4,5 et 6 concernent le monitoring d’Azure Biztalk Services.
Monitoring de Biztalk Services
Le monitoring offert par le portail nous permet de visualiser l’ensemble des requêtes qui ont été traitées par notre service Biztalk .
Le monitoring nous permet de voir les détails des données transmises à l’entreprise Z. Ainsi nous avons la possibilité de télécharger ces données (cryptées ou non) afin de valider ce que nous avons transféré. Nous sommes uniquement autorisé à faire cela car nous sommes sur un abonnement de type développeur. A ce jour, seuls les abonnements développeur et premium permettent de télécharger ce type de log.
De la même manière nous pouvons voir l’ensemble des paramètres du header de la requête qui sont envoyés à l’entreprise Z. Cela est assez efficace surtout quand on a besoin d’ajuster les paramètres requis.
Propriétés du header
L’entreprise Z a pour exigence d’avoir le le nom du fichier (Filename) dans le header de la requête car ce dernier est utilisé en interne pour des traitements particuliers.
Biztalk services supporte plusieurs propriétés dont celle qui est demandée spécifiquement par l’entreprise émettrice de factures. Ci-dessous, vous trouverez le code concernant l’envoi des messages vers notre service Biztalk:
private static string SendMessageToBridge(IProtocolHeader header, string address, byte[] messageBytes, string token, string contentType, string sourceFile)
{
ServicePointManager.ServerCertificateValidationCallback = delegate(object s, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; };
string response;
using (var webClient = new HttpRequestWebClient())
{
webClient.Headers[HttpRequestHeader.Authorization] = string.Format(WrapProtocolConstants.WrapTokenForHeader, HttpUtility.UrlDecode(token));
webClient.Headers.Add(header.CustomKeysValues);
webClient.Headers[HttpRequestHeader.ContentType] = contentType;
webClient.Headers["FileName"] = "AS2_" + sourceFile;
byte[] uploadData = webClient.UploadData(address, "POST", messageBytes);
response = Encoding.UTF8.GetString(uploadData);
}
return response;
}
Nous constaterons après une nouvelle requête que la clé que nous souhaitions se retrouve bien dans les propriétés exposées pour être utilisé par l’entreprise Z.
Feedback
- Lors de l’implémentation de ce service, la MSDN nous a induit en erreur sur le passage de certains paramètres (notamment Message-ID) concernant le header de la requête. Le mieux alors c’est de lire la RFC associée au protocole AS2 au paragraphe 5.3.3.
- Ce qui est intéressant, d’un point de vue technique, c’est que notre exemple ne nécessite pas de package spécifique lié à Azure.
- Ici nous avons exposé un cas simple d’utilisation car nous n’avons pas l’utilité de transformer les données qui transitent entre le Bridge source et le Bridge destination. Néanmoins, si nous avions ce type d’opération à réaliser alors il nous aurait fallut l’utilisation de VS 2012, ce qui aujourd’hui pourrait être un fardeau pour un développeur ainsi que pour l’entreprise qui doit mettre en place ce type de solution.
- Il est dommageable de devoir souscrire un abonnement de type premium pour une mise en production pour y observer les données transitées entre nos entreprises. Par ailleurs, à moins de laisser un abonnement de type Développer, ce dernier n’a pas l’option de haute disponibilité et donc aucun support en cas de crash de l’application.
