XMDS Specification/fr

Description
XMDS est un service web SOAP fonctionnant avec le serveur Xibo pour la communication avec les clients.

XMDS est auto-documenté en différents degrés via WSDL. Le schéma WSDL est toujours accessible sur http://votre.serveur.xibo/xmds.php?wsdl La dernière version de XMDS WSDL est attachée à cet article.

Gestion de version
En gros, chaque fois que le client appelle le service web, il fera référence à la version du schéma XMDS qu'il supporte. La réponse du serveur inclut la version du schéma qu'il supporte. Si la révision de ces deux numéros differt, le client se mettra en mode hors connexion et jouera uniquement les médias actuellement en cache.

Pseudocode
L'ordre des événements lors de l'utilisation du service SOAP est à peu près comme suit :

 Le Client se connecte et appel registerDisplay Si l'écran est déjà enregistré, XMDS retourne "L'Écran est actif et pret à fonctionner." Si l'écran est nouveau, XMDS retourne "L'Écran est ajouté et est en attente d'autorisation d'approbation d'un administrateur". L'utilisateur doit maintenant autoriser l'Écran dans Gestion->Écran sur l'Administration du serveur.

Note: ''Ici, l'implémentation des clients differt. Le client .Net met en œuvre un registre de routine comme une tâche de configuration dans une interface graphique accessible à partir du menu de démarrer sous Windows. Le client Java ne dispose pas d'interface graphique par exemple, et devra appeler à maintes reprises le web service XMDS jusqu'à ce qu'il soit dit que "L'Écran est actif et pret à fonctionner.''

Le Client appel requiredFiles Le Client appel getFile sur chaque fichier renvoyé par requiredFiles, et remplit le cache de la Blacklist locale avec les informations des éléments de la Blacklist. Le Client appel schedule pour récupérer la liste des mises en pages qui devraient être en cours de lecture, along with their start and finish times.

Note: ''Cet appel ne peut avoir lieu indépendamment des 2 et 3, mais sans mise en page, il devrait être en mesure de fonctionner jusqu'à ce que tous les fichiers soit disponibles et prêts à l'emploi, les mettres dans cet ordre simplifie la mise en œuvre de clients. Le Client .NET a été implémenté dans ce sens. Le client Java implémente un thread séparé pour les points 2,3 et 4 donc l'interaction est plus complexe, mais cet arrangement permet d'accélérer le temps de planification des requêtes du serveur au retour sur le client, en particulier lorsque des fichiers volumineux ou de grandes volumes de fichiers sont concernés.''

Le Client reourne les logs d'informations requis par ReceiveXmlLog en tant que valeur o</li> Le Client référence dans la Blacklists tous les médias qui posent problème (ex : fichiers corrompus, vidéos avec des codecs manquants) par son type et son ID ainsi que le motif. Cela permettra d'éviter que les médias soit envoyés au client à nouveau jusqu'à ce que l'utilisateur intervienne. Le client doit garder un cache local de la Blacklist pour les appels à requiredFiles.</li> </ol>

Méthodes
Suit quelques notes prises lors de l'exécution du Client Java sur la façon d'interagir avec le service web SOAP. C'est à un niveau abstrait. Exactement le format XML passé entre le client et le service a été laissée à la librarie Apache Axis.

registerDisplay
registerDisplay(serverKey,hardwareID,displayName,schemaVersion)


 * serverKey - String. Doit correspondre à la Clef Serveur enregistrée sur le serveur (Menu: Maintenance -> Configuration)
 * hardwareID - String. Identifiant unique du client. Longueur maxi. de 40 caractères. Généralement implémenté par un hash SHA1 ou MD5 de données unique.
 * displayName - String. Nom qui désigne cet Écran.
 * schemaVersion - String. La version du schéma XMDS implémenter par le client.

Cela doit être demandé avant toute autre interaction avec le serveur. Sa fonction est de définir un nouvel Écran sur les saisies hardwareID - à moins qu'un Écran avec un hardwareID existe déjà. En conséquence, hardwareID doit être unique.

Retourne en valeur le status de l'enregistrement du client.

requiredFiles
requiredFiles (serverKey,hardwareID,schemaVersion)


 * serverKey - String. Doit correspondre à la Clef Serveur enregistrée sur le serveur (Menu: Maintenance -> Configuration)
 * hardwareID - String. Identifiant unique du client. Longueur maxi. de 40 caractères. Généralement implémenté par un hash SHA1 ou MD5 de données unique.
 * schemaVersion - String. La version du schéma XMDS implémenter par le client.

Le code suivant correspond à une structure XML du serveur qui décrit tous les fichiers nécessaires programmé pour être lu par ce client.

<?xml version="1.0"?> <file type="media" path="6.jpg" id="6" size="" md5=""/> <file type="media" path="8.jpg" id="8" size="" md5=""/> <file type="layout" path="1" md5="0781e57843b9fe70759b99504278737f"/> <file type="media" path="7.jpg" id="7" size="" md5=""/> <file type="media" path="8.jpg" id="8" size="" md5=""/> <file type="media" path="6.jpg" md5="" size=""/> <file type="layout" path="2" md5="ef74f46cd4844676494863f84dab2506"/>

Chaque élément "files" (fichier) à un atrribut "type". "media" sont des fichiers multimédia requis pour la mise en page (par exemple, jpeg, des vidéos, flash, etc), "layout" types de fichiers XLF décrivant des mises en page. Chaque élément dispose de fichier et somme MD5 et la taille du fichier afin que le client puisse vérifier si elle a déjà cette version du fichier avant de le télécharger. Le troisième attribut est de type "blacklist" qui est le chemin vers un fichier XML contenant la liste noire des médias. Le client doit utiliser cette information pour ne pas tenter de lire ces médias (puisqu'ils ont posé des problèmes auparavant).

getFile
getFile (serverKey,hardwareID,filePath,fileType,chunkOffset,chunkSize,schemaVersion)


 * serverKey - String. Doit correspondre à la Clef Serveur enregistrée sur le serveur (Menu: Maintenance -> Configuration)
 * hardwareID - String. Identifiant unique du client. Longueur maxi. de 40 caractères. Généralement implémenté par un hash SHA1 ou MD5 de données unique.
 * filePath - String. Le nom du fichier média à télécharger. Given to us by the "path" attribute in requiredFiles for this item. For a media item, this will be a full filename. For a layout, this will be just the layout id number. If the client stores this layout to disc, it should give it an appropriate extension (ex : .xlf)
 * fileType - String. The type of this file (layout | media | blacklist). Given to us by the "type" attribute in requiredFiles for this item.
 * chunkOffset - int bytes. Where to start downloading from. 0 is the beginning of the file. Used to download a section of the file. Always 0 when dealing with a "layout" or "blacklist" type.
 * chunkSize - int bytes. How much of the file to download in one go. 512,000 is a sensible number for "media" types. Always 0 when dealing with a "layout" or "blacklist" type - 0 signifies the whole content.
 * schemaVersion - String. The XMDS schemaVersion implemented by this client.

Returns a base64 encoded byte array of length chunkSize or size depending on which type we are dealing with. Should be called multiple times for large media type files, incrementing chunkOffset by chunkSize at each call. The returned output can then be concatenated to form the original file.

schedule
schedule (serverKey, hardwareID, schemaVersion)


 * serverKey - String. Must match the SERVER_KEY in the server configuration (Menu: Maintenance -> Configuration)
 * hardwareID - String. Unique to the client string. Max length 40 characters. Generally implemented as an SHA1 or MD5 hash of some unique data.
 * schemaVersion - String. The XMDS schemaVersion implemented by this client.

Returns an XML structure in a string describing all the layouts that should be playing around now, along with their start and finish times:

<?xml version="1.0"?> <layout file="1" fromdt="2050-12-31 00:00:00" todt="2050-12-31 00:00:00" scheduleid=""/> <layout file="2" fromdt="2008-12-08 08:00:00" todt="2008-12-11 21:19:00" scheduleid="1"/>

Each layout element represents a layout to be shown. The "file" attribute refers to the filePath parameter from getFile and is also the layoutID number. This identifies the XLF to play. The "fromdt" is a string representing the time the layout should start being shown. The "todt" is a string representing the time the layout should stop being shown. The "fromdt" and "todt" fields are in the following format "yyyy-mm-dd hh:mm:ss".

receiveXmlLog
receiveXmlLog (serverKey, hardwareID, xml, schemaVersion)


 * serverKey - String. Must match the SERVER_KEY in the server configuration (Menu: Maintenance -> Configuration)
 * hardwareID - String. Unique to the client string. Max length 40 characters. Generally implemented as an SHA1 or MD5 hash of some unique data.
 * xml - String. XML Structure as defined below. This is used for reporting Errors, Audit and Display Statistics.
 * schemaVersion - String. The XMDS schemaVersion implemented by this client.

The XML schema for this communication is documented here: Log XML Schema.

Returns true on success and a SOAP Fault on failure.

blacklist
blacklist (serverKey, hardwareID, mediaID, type, reason, schemaVersion)


 * serverKey - String. Must match the SERVER_KEY in the server configuration (Menu: Maintenance -> Configuration)
 * hardwareID - String. Unique to the client string. Max length 40 characters. Generally implemented as an SHA1 or MD5 hash of some unique data.
 * mediaID - Int. ID of the media being blacklisted.
 * type - String (All|Single). If this is All then the media will be blacklisted for ALL displays that use it. If this is Single then it will only be blacklisted for the display described by hardwareID)
 * reason - String. The reason for the blacklist. This is generally a short user readable description of the error - and not an error code. But the string can contain both.
 * schemaVersion - String. The XMDS schemaVersion implemented by this client.

Returns true on success and a SOAP Fault on failure.