Architecture
SAP BusinessObjects Mobile permet aux utilisateurs d'accéder à distance aux mêmes rapports, métriques et données en temps réel Business Intelligence (BI) disponibles dans les applications client de bureau depuis un appareil sans fil. Le contenu est optimisé pour les périphériques mobiles de sorte que les utilisateurs peuvent facilement accéder aux rapports courants, naviguer dans ces rapports et les analyser sans aucune formation supplémentaire.
Avec SAP BusinessObjects Mobile, les responsables et les techniciens de l'information disposent en permanence de données à jour sur la base desquelles ils peuvent prendre des décisions avisées. Les
équipes de vente et service après-vente peuvent fournir à tout moment des informations pertinentes relatives au client, au produit et à l'ordre de travail.
SAP BusinessObjects Mobile prend en charge une large gamme de périphériques mobiles, y compris
BlackBerry, Windows Mobile et Symbian.
Pour en savoir plus sur l'installation, la configuration et le déploiement Mobile, reportez-vous au
Guide d'installation et de déploiement de SAP BusinessObjects Mobile. Pour en savoir plus sur l'utilisation de SAP BusinessObjects Mobile, reportez-vous au guide
Utilisation de SAP BusinessObjects Mobile.
3.4 Workflows de processus
Lors de l'exécution de tâches telles que la connexion, la planification ou la visualisation d'un rapport, des flux d'informations qui transitent sur le système et les serveurs communiquent entre eux. La section suivante décrit certains des flux de traitement tels qu'ils se produisent dans la plateforme de BI.
Pour visualiser d'autres workflows de processus avec des supports visuels voir les tutoriels produit officiels de la plateforme SAP BusinessObjects Business Intelligence 4.x à l'adresse : http://scn.sap.com/docs/DOC-8292
3.4.1 Démarrage et authentification
79
3.4.1.1 Connexion à la plateforme SAP BusinessObjects Business Intelligence
Ce workflow décrit une connexion utilisateur à une application Web de la plateforme SAP
BusinessObjects Business Intelligence à partir d'un navigateur Web. Ce workflow s'applique aux applications Web telles que la zone de lancement BI et la CMC (Central Management Console).
1.
Le navigateur (client Web) envoie la demande de connexion via le serveur Web au serveur d'applications Web où s'exécute l'application Web.
2012-05-10
Architecture
80
2.
Le serveur d'applications Web détermine qu'il s'agit d'une requête de connexion. Le serveur d'applications Web envoie le nom d'utilisateur, le mot de passe et le type d'authentification au CMS pour authentification.
3.
Le CMS valide le nom d'utilisateur et le mot de passe par rapport à la base de données appropriée.
Dans ce cas, l'authentification Enterprise est utilisée et les références de l'utilisateur sont authentifiées par rapport à la base de données système du CMS.
4.
Une fois la validation réussie, le CMS crée une session pour l'utilisateur dans la mémoire.
5.
Le CMS envoie une réponse au serveur d'applications Web pour l'aviser que la validation a réussi.
6.
Le serveur d'applications Web génère un jeton de connexion pour la session utilisateur dans la mémoire. Durant la reste de la session, le serveur d'applications Web utilise le jeton de connexion pour valider l'utilisateur auprès du CMS. Le serveur d'applications Web génère la page Web suivante pour l'envoyer au client Web.
7.
Le serveur d'applications Web envoie la page Web suivante au serveur Web.
8.
Le serveur Web envoie la page Web au client Web, où elle s'affiche dans le navigateur de l'utilisateur.
3.4.1.2 Démarrage du SIA
Un SIA (Server Intelligence Agent) peut être configuré pour démarrer automatiquement avec le système d'exploitation hôte ou manuellement avec le CCM (Central Configuration Manager).
Un SIA extrait des informations sur les serveurs qu'il gère depuis un CMS (Central Management Server).
Si le SIA utilise un CMS local et que celui-ci n'est pas en cours d'exécution, le SIA le démarre. Si un
SIA utilise un CMS distant, il tente de s'y connecter.
Une fois le SIA lancé, la séquence d'événements ci-après est exécutée.
1.
Le SIA recherche un SMS dans son cache.
a.
Si le SIA est configuré pour démarrer un CMS local et que le CMS n'est pas en cours d'exécution, le SIA le démarre et se connecte.
b.
Si le SIA est configuré pour utiliser un CMS en cours d'exécution (local ou distant), il tente de se connecter au premier CMS dans son cache. Si ce CMS n'est pas disponible, il tente de se connecter au CMS suivant dans son cache. Si aucun des CMS mis en cache n'est disponible, le SIA attend qu'un CMS soit disponible.
2.
Le CMS confirme l'identité du SIA pour s'assurer qu'il est valide.
3.
Une fois le SIA connecté à un CMS, il demande une liste de serveurs à gérer.
Remarque :
Le SIA ne stocke pas d'informations sur les serveurs qu'il gère. Les informations de configuration qui déterminent quel serveur est géré par un SIA sont stockées dans la base de données système du CMS et sont extraites du CMS par le SIA à son démarrage.
4.
Le CMS demande à la base de données système du CMS la liste des serveurs gérés par le SIA.
La configuration de chaque serveur est également extraite.
5.
Le CMS renvoie au SIA la liste des serveurs et leur configuration.
2012-05-10
