Sap Guixt

 

Scriptes GuiXT dans le SAP Web Repository

Les scriptes GuiXT, les images (gif, jpg) et les InputScript peuvent être stockés:

• dans des fichiers locaux, par ex.: sous C:\GuiXT\Scripts
• sur un serveur de fichiers central, par ex.:  \\p00145\GuiXT\Scripts
• sur un serveur http, par ex.: http://www.synactive.com/demo.d.45
• sur un serveur ftp, par ex.: ftp://synactive.com/demo.d.45
• dans le SAP Web Repository (base de données R/3), par ex.: sapwr:z.guixt.demo

Chacune de ces solutions offre des avnatages et inconvénients spécifiques:

• les fichiers locaux sont idéaux lors du développement et pour des petits groupes d’utilisateurs
• les serveurs centraux facilitent l’administration sans créer une charge sur la base de données R/3
• les serveurs http et ftp sont un bon choix lorsqu’il y a plusieurs réseaux locaux
• le SAP Web Repository offre une administration centrale avec l’accès au module de transport et de correction du R/3. Grâce au méchanisme de cache intégré au GuiXT chaque objet n’est chargé qu’une seule fois au cours d’une session SAP. Ainsi la charge sur la base de données et sur le réseau local reste faible.

Le nom devra commencer par un Z, car tous les objets individuels commencent par un Z dans le SAP Web Repository.

Exemple: sapwr:z.guixtobjects

Spécification dans un script
Si vous spécifiez une image ou un InputScript sans spécifier le répertoire, GuiXT cherchera automatiquement là où se trouve le scripte, c’est à dire également dans le Web Repository. Vous pouvez également spécifier explicitement le Web Repository (ceci est également possible dans des scriptes locaux), par exemple:

Image   … “SAPWR:Z.Images.logo.gif”

Spécification optionelle d’un système SAP différent
Si vous désirez accéder à un autre système SAP, vous pouvez spécifier son identification en utilisant l’option dest=xxx.

Exemple: sapwr,dest=S46:z.guixtobjects

Dans ce cas l’accès est contrôlé selon l’indication dans le fichier saprfc.ini (se trouve la plupart du temps dans le répertoire de travail SAP Workdirectory). Pour plus de renseignements, veuillez-vous réporter à la documentation SAP sur Remote Function Call.

Pour le transport des objets entre plusieurs systèmes R/3 (développemnet, test, production), il vous faut une classe de développement que vous pouvez définir à l’aide de la transaction SE80.

Transaction SE80 (Créer classe de développement)

Le nom de l’objet se compose de l’idientification que vous avez choisie et spécifiée dans le profile GuiXT, par exemple Z.GUIXT, d’un point suivi d’un nom de fichier normal avec l’extension .txt, .gif,…

Exemples:

Z.GUIXT.FLOGON.TXT
Z.GUIXT.SAPMF05A.F0100.TXT
Z.GUIXT.FB01PIECE.TXT
Z.GUIXT.LOGO.GIF

Veuillez noter les points suivants:

• Choisissez “données binaires” dans l’écran initial de SMW0
• Ne changez pas le type BIN lors du téléchargement du fichier
• Un titre explicite vous facilitera l’identification par la suite

Transaction SMW0 (SAP Web Repository)

Choisissez “données binaires” et cliquez sur “Recherche”

Vous pouvez indiquer le nom de manière générique

Dans l’écran d’affichage vous avez la possibilité de copier et de créer des objets

Veuillez veiller au nom correct de l’objet et à donner un titre suffisamment explicite

Association à la classe de développement ou objet local lors de tests

Transmission du fichier local, conservez le format binaire

Libération du module de fonctions WWW_GET_MIME_OBJECT
Selon la version de R/3 il peut être nécessaire de libérer le module de fonction WWW_GET_MIME_OBJECT à l’aide de la transaction SMW0. GuiXT utilise ce module de fonction pour la lecture du Web Repository.

Choisissez la fonction Libération->Module de fonction (F7) dand le menu Libération. Vous pouvez afficher une liste de tous les modules de fonction libérés:

Si le module WWW_GET_MIME_OBJECT n’y est pas encore, vous pouvez provoquer la libération de la fonction en saisissant le nom WWW_GET_MIME_OBJECT et en cliquant sur “Libération”.