Instructions sur Office Mobile Service 2010 (Partie 2/3)

Résumé :  Découvrez comment créer et héberger des services Web pour Microsoft Office 2010 Mobile Service (OMS). Cet article fournit des conseils et des recommandations pour le développement de pages Web pour OMS. Notez qu’Office Mobile Service dans Office 2010 est la version mise à jour d’Outlook Mobile Service dans Microsoft Office System 2007. (12 pages imprimées)

Dernière modification : lundi 9 mars 2015

S’applique à : Excel 2010 | Office 2007 | Office 2010 | Office Mobile | Open XML | Outlook 2010 | Outlook Mobile | PowerPoint 2010 | SharePoint Foundation 2010 | SharePoint Server 2010 | VBA | Word 2010

Dans cet article
Introduction aux services Web pour OMS
Recommandations pour le développement côté service
Pages Web
Journalisation du trafic des messages
Conclusion
Ressources supplémentaires

Contenu

  • Introduction aux services Web pour OMS

  • Recommandations pour le développement côté service

  • Pages Web

  • Journalisation du trafic des messages

  • Conclusion

  • Ressources supplémentaires

Introduction aux services Web pour OMS

Microsoft Office 2010 Mobile Service (OMS) est le composant de messagerie développé pour Microsoft Outlook 2010 et Microsoft SharePoint 2010. Avec OMS, les utilisateurs peuvent intégrer en toute transparence les capacités mobiles d’Outlook à leurs appareils mobiles, ainsi que recevoir les alertes par message texte d’un site SharePoint.

Le client OMS, qui est intégré dans Outlook et SharePoint, envoie des messages texte ou multimédia à un service Web qui est créé et hébergé par des partenaires qui sont soit des opérateurs soit des fournisseurs de services de contenu de messages mobiles. Le service Web livre ensuite le message à un centre de service de messages texte ou multimédia d’opérateurs.

Cet article est le second d’une série de trois articles qui introduit OMS et fournit des conseils d’utilisation du service. Pour obtenir des exemples de code et des informations sur le flux de messages entre les fournisseurs de services Web OMS et les clients, voir Instructions relatives à Office 2010 Mobile Service (partie 1/3). Pour des informations sur le schéma XML des données transmises entre les fournisseurs Web OMS et les clients OMS, voir Instructions relatives à Office 2010 Mobile Service (partie 3/3).

Recommandations pour le développement côté service

Instructions relatives à Office 2010 Mobile Service (partie 1/3) présente les protocoles de communication entre le service Web OMS et le client OMS. Ensuite, nous examinerons d’autres aspects à prendre en considération pour développer ou héberger un service Web OMS, puis des exemples de pages Web utilisables pour abonner des utilisateurs à ce service seront fournis.

Configuration système de base requise

Le développement de service Web OMS ne requiert pas un système complexe. Vous pouvez utiliser la technologie Microsoft préexistante pour créer un service Web standard. La configuration système de base requise est la suivante :

  • Microsoft Visual Studio .NET 2003, Visual Studio 2005, Visual Studio 2008 ou Visual Studio 2010.

  • Microsoft Windows Server 2003 ou Windows Server 2008.

  • Microsoft SQL Server 2000, SQL Server 2005 ou SQL Server 2008.

Pour de meilleurs résultats, il est recommandé de créer le service Web OMS en utilisant Visual Studio et de l’héberger sur Windows Server 2003 ou ultérieur avec Internet Information Services (IIS) 6.0 ou ultérieur. SQL Server est recommandé pour la journalisation des transactions côté serveur.

Considérations sur les performances et la capacité

Avant de considérer l’exploitation complète du service, il est très important de tester rigoureusement les performances et la capacité afin d’allouer le matériel et la bande passante Internet/Intranet convenables. Les tests de performances permettent aux fournisseurs de services de mesurer la capacité du service Web et d’identifier les bogues qui pourraient sinon passer inaperçus. Les tests de performances doivent mesurer le temps de réponse des demandes d’un utilisateur et être répartis en séries de tests normale, de pointe et sous contrainte.

Le but de la série de tests normale est de mesurer les variations de la courbe du temps de réponse sur une période continue (par exemple, 12 heures). La série de tests de pointe mesure les variations du temps de réponse aux heures de pointe (par exemple, heures de bureau). La série de tests sous contrainte mesure la stabilité du service et les variations du temps de réponse avec un volume élevé de demandes sur une très courte période. Les tests de performances peuvent être effectués en exécutant simultanément la même applet ou le même script sur de nombreux ordinateurs clients qui envoient des demandes de messages texte ou multimédia au service Web.

Il est impossible de créer le véritable environnement réel nécessaire pour les tests sous contrainte, qui pourrait impliquer plusieurs milliers d’ordinateurs clients envoyant des demandes simultanément. Par conséquent, des simulations mathématiques sont employées pour déterminer le nombre d’ordinateurs clients requis pour simuler un scénario réel. Par exemple, pour simuler une situation réelle de 5 000 utilisateurs envoyant chacun un message texte toutes les 30 minutes et attendant un temps de réponse du service de 3 secondes, il vous faudrait peut-être déployer 9 ordinateurs clients de test qui envoient des messages texte simultanément et de façon répétée.

Pages Web

Les pages Web sont développées par les fournisseurs de services Web OMS et sont affichées sur le site Web du fournisseur de service. L’URL de la page d’abonnement au fournisseur de services doit être définie dans l’élément signUpPage de la chaîne XML serviceInfo. Ces pages sont conçues pour guider l’utilisateur tout au long du processus d’abonnement, pour gérer les informations personnelles et la configuration de l’utilisateur et pour configurer un compte dans Outlook ou SharePoint pour le service Web.

URL de services Web multiples

Pour les fournisseurs de services qui rassemblent des services de plusieurs opérateurs, il est possible de concevoir et héberger plusieurs services Web OMS afin que des opérateurs particuliers puissent avoir des paramètres de service spécifiques, tels que les limites de longueur des messages SMS (Short Message Service) ou de taille des messages MMS (Multimedia Messaging Service).

En conséquence, les pages Web d’abonnement doivent être conçues pour respecter cette condition. Les utilisateurs sont guidés vers différentes URL de service en fonction de leurs opérateurs lorsqu’ils ajoutent un compte dans Outlook ou SharePoint. Après leur inscription à un service, les utilisateurs sont guidés vers l’URL du service correspondant s’ils souhaitent reconfigurer leurs comptes.

Page d’accueil

Les fournisseurs de services Web OMS doivent créer une page d’accueil qui est la page par défaut ouverte par un utilisateur. Sur cette page, les utilisateurs doivent pouvoir obtenir les informations sur les fonctionnalités du service Web et du client. Les nouveaux utilisateurs doivent pouvoir s’inscrire au service OMS et les utilisateurs abonnés pouvoir vérifier et mettre à jour leurs informations personnelles, par exemple leur mot de passe, et configurer leurs options de réponse.

La page d’accueil doit contenir les informations suivantes :

  • Présentation OMS : introduction informelle aux fonctionnalités OMS pour présenter OMS aux utilisateurs.

  • Configuration système requise : pour utiliser OMS, les utilisateurs doivent installer Outlook 2010 ou SharePoint 2010, et doivent donc vérifier leur version de Microsoft Office avant de s’abonner.

  • Informations de dépannage.

  • Entrée d’inscription et de connexion.

  • Un lien hypertexte ou un bouton pour que les nouveaux utilisateurs s’abonnent au service OMS, et un message comme « Cliquez sur S’inscrire pour s’abonner au service OMS ».

Fournissez aux utilisateurs existants une sorte de zone de connexion pour qu’ils puissent se connecter à leurs comptes OMS en entrant leur ID d’utilisateur, ou leur numéro de téléphone mobile, et leur mot de passe. Si un utilisateur oublie son mot de passe, la page Web doit proposer un moyen pour le récupérer. Lorsqu’un utilisateur se connecte avec succès, il doit pouvoir afficher et modifier son profil, ses paramètres de réponse, etc. La figure 1 est un exemple de page d’accueil OMS.

Figure 1. Page d’accueil OMS

Page d’accueil OMS

Page d’inscription

Créez une page Web appelée Page d’inscription qui guide les utilisateurs pas à pas lors de leur inscription au service Web OMS. Pour entrer sur ce site, l’utilisateur doit cliquer sur S’inscrire dans la page d’accueil. Pour s’inscrire au service, l’utilisateur doit renseigner les champs affichés dans la figure 2. L’ID utilisateur doit être une chaîne d’identification unique définie par l’utilisateur et peut être son numéro de téléphone mobile. Ce champ est facultatif selon les exigences propres aux fournisseurs de services.

Figure 2. Page d’inscription

Page d’inscription

Page Paramètres de configuration

Créez une page Paramètres de configuration qui permet aux utilisateurs de modifier leur paramètres Réponse et Notification.

Le message entrant décrit dans la section « Empaquetage des messages mobiles entrants » de l’article Instructions relatives à Office 2010 Mobile Service (partie 1/3) est envoyé par le service OMS en fonction des options de réponse prédéfinies. L’option Réponse permet deux destinations facultatives : Répondre au téléphone mobile ou Répondre à la boîte aux lettres.

Si un utilisateur sélectionne l’option Répondre à la boîte aux lettres (voir Figure 3), l’utilisateur doit ajouter l’adresse SMTP (donnée par le fournisseur de service) à la liste Expéditeurs approuvés d’Outlook. Cela garantit que les réponses aux messages mobiles envoyées par le client OMS ne sont pas traitées comme du courrier indésirable. De plus, le service Web doit envoyer aux utilisateurs qui sélectionnent cette option Réponse un message électronique de bienvenue qui fournit la liste des fonctionnalités clés OMS et les instructions pour activer la boîte aux lettres et utiliser OMS.

Par défaut, l’option est désactivée. Les utilisateurs qui sélectionnent cette option peuvent entrer le nombre maximum de messages par jour à transférer vers leur appareil mobile. Il peut s’agir de messages basés sur des règles OMS ou de rappels OMS. Par défaut, ce nombre maximum est 30. Le fournisseur de service peut compter ces messages en utilisant l’élément sourceType dans xmsData. Chaque jour, pour chaque utilisateur, le fournisseur de service compte le nombre total de messages envoyés avec sourceType="ruleBased" ou sourceType="reminder". Ci ce nombre est supérieur au maximum défini sur la page Paramètres de configuration, le fournisseur de service doit retourner un code d’erreur au client OMS. Cette erreur doit avoir un attribut code valant other et avoir le texte suivant dans l’élément content : « Vous avez atteint la limite prédéfinie de notifications et de rappels que vous pouvez recevoir aujourd’hui ».

Figure 3. Page Paramètres de configuration

Page Paramètres de configuration

Page Infos utilisateur

La page Infos utilisateur permet aux utilisateurs d’afficher leurs informations personnelles. Elle contient les informations d’inscription, les informations de configuration et les informations de service. La figure 4 est un exemple de page Infos utilisateur.

Figure 4. Page Infos utilisateur

Page Infos utilisateur

Page Changer le mot de passe

La page Changer le mot de passe permet aux utilisateurs de gérer leurs informations personnelles, par exemple leur mot de passe et leur numéro de téléphone mobile. La figure 5 est un exemple de page Changer le mot de passe.

Figure 5. Page Changer le mot de passe

Page Modifier le mot de passe

Ajout de comptes dans Outlook

Avec OMS, les utilisateurs peuvent configurer des comptes dans Outlook 2010 pour leur service Web en cliquant simplement sur un bouton. Pour que cela fonctionne, les fournisseurs de services peuvent ajouter un lien contenant le protocole requis ou ajouter une ligne dans leur code pour retourner une URL de protocole avec les informations de l’utilisateur. Lorsque l’utilisateur clique sur ce lien, ou applique une action spécifique qui déclenche le code, OMS affiche un message qui demande à l’utilisateur s’il souhaite ajouter ce compte à OMS. Si l’utilisateur clique sur Oui, le gestionnaire de comptes OMS s’ouvre et les informations d’inscription de l’utilisateur sont ajoutées automatiquement. L’URL suivante est un exemple :

oms:https://211.136.85.91/omsv3/xmsservice.asmx?UserID=13910021012

L’URL comprend les éléments suivants :

  • Schéma (oms:https://)

  • Serveur (211.136.85.91)

  • Chemin d’accès (omsv3/xmsservice.asmx)

  • Demande (UserID=12910021012)

Conformément à RFC 1738, dans les URL, seules les parties Serveur et Chemin d’accès peuvent être insensibles à la casse et les autres sont sensibles à la casse. Le schéma d’URL pour « oms » est obligatoire et doit être en minuscules. L’URL du service Web OMS doit commencer par « https ».

Le composant Demande de l’URL (tout le texte qui suit le point d’interrogation) contient zéro ou plusieurs paramètres séparés par le caractère &. Chaque paramètre doit être défini sous la forme « name=value ». Lorsque l’URL de protocole ne contient pas le composant Demande, elle est traitée comme un compte vide pour le fournisseur de service, sans aucun paramètre spécifié.

Insérez un lien ou un bouton Ajouter comme compte Outlook sur la page Infos utilisateur qui démarre le processus de création de compte OMS, comme illustré dans la figure 6.

Figure 6. Boîte de dialogue Ajouter comme compte Outlook

Ajouter comme compte Outlook

Publication du service Web

Le service Web développé pour OMS peut être publié sur Office Marketplace sur Microsoft Office Online. Pour plus d’informations, voir Devenir un fournisseur Office Marketplace.

Journalisation du trafic des messages

Le but de la journalisation du trafic des messages est d’acquérir une meilleure perception des utilisateurs OMS et de déterminer et faire le suivi des erreurs les plus fréquentes rencontrées par les utilisateurs. Ces informations sont précieuses pour améliorer le service.

Pour concevoir la base de données décrite dans cette section, vous devez créer les tables suivantes :

  • userInformation

  • messageType

  • errorCodes

  • outgoingLog

  • outgoingErrorLog

  • receivingLog

La table userInformation enregistre les informations générales sur chaque utilisateur, notamment les propriétés comme userId (ID unique et intraçable, utilisé pour différentier les utilisateurs de façon anonyme), les services souscrits, tels que service de messages texte, la durée souscrite, la date d’expiration, la date d’abandon et les paramètres de réponse.

La table messageType définit les types de message à suivre dans les messages sortants. Avec cette table, vous pouvez distinguer les messages créés en tant que messages texte de ceux générés en tant que courrier électronique. La définition des champs utilisés dans la table messageType est indiquée dans le Tableau 1. Les types de message prédéfinis qui doivent apparaître comme données dans la table messageType sont répertoriés dans le Tableau 2.

Tableau 1. Définition de la table MessageType

Champ

Type

typeCode

digit

typeName

string

Tableau 2. Types de message prédéfinis

typeCode

typeName

100

Message texte envoyé par un inspecteur de courrier électronique.

101

Message texte envoyé par un inspecteur OMS.

102

Message texte envoyé par un inspecteur OMS à l’heure programmée.

103

Rappel transféré en tant que message texte.

104

Message texte transféré à cause d’une notification basée sur une règle.

105

Synthèse de calendrier envoyée sous forme de message texte.

200

Message MMS envoyé par un inspecteur de courrier électronique.

201

Message MMS envoyé par un inspecteur OMS.

202

Message MMS envoyé par un inspecteur OMS à l’heure programmée.

203

Rappel transféré en tant que message MMS.

204

Notification basée sur une règle transférée sous forme de message MMS.

205

Synthèse de calendrier envoyée sous forme de message MMS.

300

Message texte envoyé par un serveur SharePoint en tant qu’alerte.

000

Tout autre type non spécifié.

La définition de la table errorCodes est indiquée dans le Tableau 3. La table errorCodes doit inclure les codes d’erreur utilisés par le service Web OMS.

Tableau 3. Définition de la table ErrorCodes

Champ

Type

typeCode

Digit

typeName

String

La table outgoingLog journalise tous les messages envoyés par le service Web OMS, comme indiqué dans le Tableau 4.

Tableau 4. Définition de la table OutgoingLog

Champ

Type

Description

messageID

Digit

ID identité.

userID

String

ID unique et intraçable, utilisé pour différentier les utilisateurs de façon anonyme.

sendTime

dateTime

Date et heure d’envoi du message.

messageType

Digit

Clé étrangère du champ [MessageType].typeCode.

splitNo

digit

Numéro pour un long message qui a été divisé en plusieurs messages.

DBMix

Digit

0- Anglais, 1- Multilingue.

recipientNo

Digit

Nombre de destinataires.

slideModeFlag

Digit

Avec un message MMS, indique s’il utilise le mode diapositive : 0-Mode diapositive, 1-Autre.

contentType

String

Le type de contenu MIME (Multipurpose Internet Mail Extensions) de ce message, tel que "text/plain".

successFlag

Digit

0-Réussite, 1-Réussite partielle, 2-Échec.

La table outgoingErrorLog journalise tous les messages envoyés sans succès total, comme indiqué dans le Tableau 5. Elle journalise toutes les erreurs connexes et peut représenter de multiples erreurs sur de multiples enregistrements.

Tableau 5. Définition de la table OutgoingErrorLog

Champs

Type

Description

ID

digit

ID identité.

messageID

digit

ID du message. Cet ID doit correspondre à l’ID enregistré pour ce message dans la table outgoingLog.

errorCode

string

Clé étrangère du champ [errorCodes].[typeCode].

La table receivingLog journalise tous les messages reçus. Elle enregistre plusieurs types d’informations, comme indiqué dans le Tableau 6.

Tableau 6. Définition de la table ReceivingLog

Champs

Type

Description

messageID

digit

ID identité.

userID

string

ID unique et intraçable, utilisé pour différentier les utilisateurs de façon anonyme.

receiveTime

dateTime

Date et heure de réception de la réponse.

replyTime

digit

Options de réponse définies par les utilisateurs : 0=Répondre par courrier électronique, 1=Répondre vers téléphone mobile, 2=Les deux.

messageType

string

"SMS", "MMS" ou "Others".

contentType

string

Type de contenu MIME de ce message de réponse, comme "plain/text".

successFlag

digit

Code de l’erreur qui s’est produite (champ typeCode de la table errorCodes) ou 0 pour indiquer le succès.

La création des tables et leur utilisation comme décrit fournissent des informations utiles sur les performances du service Web OMS.

L’architecture globale d’OMS est une structure de services clients basée sur la technologie de service Web. Le client OMS encode un message mobile sous forme de message SOAP et l’envoie au service Web OMS, où il est encodé et remis à la passerelle de messages mobiles de l’opérateur. Le message est ensuite livré aux téléphones mobiles des utilisateurs prévus via les réseaux sans fil de l’opérateur. Le service Web OMS est créé et hébergé par un fournisseur de service qui est soit un opérateur de téléphonie mobile soit un revendeur (fournisseur de contenu Internet, fournisseur de service Internet ou toute société pouvant offrir un service de messagerie mobile). La spécification du service Web OMS et les protocoles de communication entre le client OMS et le service Web sont décrits dans la section « Protocoles de communication » de l’article Instructions relatives à Office 2010 Mobile Service (partie 1/3).

Les messages sont émis et reçus entre Outlook et le téléphone mobile du destinataire via le service Web OMS et l’infrastructure de l’opérateur. Les réponses du téléphone mobile du destinataire peuvent être dirigées vers la boîte de réception Outlook, l’appareil mobile de l’émetteur, ou les deux, en fonction des préférences de l’utilisateur. Pour remettre les réponses à la boîte de réception Outlook d’un utilisateur, le fournisseur de service les empaquette dans des messages électroniques SMTP selon la spécification définie par Microsoft. Pour plus d’informations, voir la section « Empaquetage des messages mobiles entrants » de l’article Instructions relatives à Office 2010 Mobile Service (partie 1/3).

Conclusion

Cet article examine d’autres aspects, tels que la journalisation du trafic des messages, à prendre en considération pour développer ou héberger un service Web OMS. Il fournit également quelques conseils pour développer un site Web afin de gérer les processus d’abonnement et de configuration pour les fournisseurs de services Web OMS. L’article Instructions relatives à Office 2010 Mobile Service (partie 3/3) présente le schéma XML des données transmises entre les fournisseurs Web OMS et les clients OMS, et donne la définition WSDL d’un service Web OMS.

Ressources supplémentaires

Pour plus d’informations, consultez les ressources suivantes :