Pour communiquer avec des APIs, le format de messages privilégié par Microsoft BizTalk Server est généralement XML ou Json. En effet il existe des composants de pipeline natifs qui, à la fois en envoi et en réception, rendent la conversion XML – Json très simple. Il s’agit respectivement du Json encoder et du Json decoder.
Cependant un langage de plus en plus utilisé par les APIs est le GraphQL. Le but de cet article est de montrer une solution permettant de communiquer en GraphQL avec une API depuis BizTalk.
La première étape est de générer l’équivalent Json de la requête GraphQL à envoyer. J’utilise pour cela Insomnia. Voici un exemple de requête GraphQL, qui permet de retrouver un ID à partir d’une référence de commande :
{order(ref: "XXX") {fulfilments {edges {node {id}}}}}
En switchant le format de GraphQL à Json dans Insomnia :
L’équivalent généré est le suivant :
{"query":"{ order(ref: \"XXX\") { fulfilments { edges { node { id } } } }}"}
Il nous reste maintenant à former ce message depuis BizTalk. Pour cela, plusieurs options sont possibles :
Pour décider ici, il faut réfléchir au degré de flexibilité que l’on souhaite. En effet le helper nous permet de rendre la structure de la requête – et notamment le nom des champs – paramétrable. A noter qu’il est également possible de le faire dans une map full xsl.
Dans cet exemple nous utilisons un helper. En prenant garde à l’échappement des caractères, voici le contenu de notre shape de construction de message avec en variable prédéfinie la référence de commande :
msgIdRequest = new System.Xml.XmlDocument(); Helper.LoadXLANGMsgFromString("{\"query\":\"{ order(ref: " + OrderReference + ") { fulfilments { edges { node { id } } } }}\"}", msgIdRequest);
Et dans le helper :
public static void LoadXLANGMsgFromString(string source, XLANGMessage dest) { var bytes = Encoding.UTF8.GetBytes(source); using (MemoryStream ms = new MemoryStream(bytes, 0, bytes.Length, false, true)) { dest[0].LoadFrom(ms); } }
Ici le helper sert uniquement à générer un message XLANG à partir d’une string, mais en l’enrichissant il pourrait contenir une logique de construction de requête plus complexe à partir des paramètres passés depuis l’orchestration.
Côté bindings, appliquer un pipeline d’envoi PassThruTransmit. En réception, un pipeline contenant un Json decoder et un XML Disassembler permettra de parser la réponse (en ayant au préalable défini un xsd) et de finalement récupérer l’ID voulu en utilisant une requête xpath par exemple.