Tivoli Service Desk 6.0 Developer's Toolkit - Guide du concepteur d'interfaces (Interface Designer)
Retour à la table des matières
L'interface CPIC (Common Programming Interface for Communications) fournit une API cohérente destinée aux applications impliquant des communications entre plusieurs applications. L'interface CPIC utilise la LU 6.2 des services SNA pour créer un ensemble de services inter-applications, qui comprend :
Les commandes CPIC sont intégrées au langage de TSD Script afin que le programmeur de TSD Script bénéficie de l'extension de ces services. Le choix de l'interface CPIC a été privilégié sur les macros de base APPC, de manière à garantir la compatibilité entre les plateformes.
La présente section a pour objet de servir de guide d'élaboration des programmes de transactions de TSD Script exploitant l'interface CPIC. Pour obtenir des informations détaillées sur la programmation SAA CPIC, reportez-vous au manuel d'IBM, Systems Application Architecture Common Programming Interface for Communications Reference, SC26-4399.
Pour permettre l'exécution des commandes CPIC, l'interface CPIC doit être installée sur votre machine. Si tel n'est pas le cas, à chaque lancement d'une commande CPIC, la boîte à outils du développeur de Tivoli Service Desk signale par un message d'erreur que le chargement de CPIC est impossible.
Les communications APPC représentent un système évolué de communications d'égal à égal.
La conversation de base est un type de conversation dans lequel des applications procèdent à des échanges de données au format train d'octets standard. Ce format contient des zones d'une longueur de deux octets (appelées zones LL) qui définissent la longueur de la mémoire tampon à respecter. Chaque regroupement de données LL s'appelle un enregistrement logique.
Une conversation est une connexion logique entre deux applications qui échangent des données via CPIC ou APPC. Il existe deux types de conversation : mappée ou de base. Une conversation connecte les applications par l'intermédiaire d'une session. Une application CPIC peut converser avec une application APPC, de même qu'avec une autre application CPIC.
Un fichier DDF (fichier de description de données) a pour fonction de mapper les relations entre les structures d'enregistrement de TSD Script et les mémoires tampons d'octets transmis.
Une LU (Unité logique) est, à proprement parler, une machine virtuelle. Outre le fait qu'il est possible de désigner chaque machine physique comme étant une LU, il est également permis de configurer plusieurs LU afin qu'elles constituent une machine physique unique. CPIC utilise uniquement les noeuds de LU Type 6.2.
Une conversation mappée désigne un type de conversation dans lequel différents partenaires échangent des enregistrements de données arbitraires, suivant des formats déterminés à l'avance.
L'interface APPC utilise un nom de mode pour désigner les propriétés de la session entre les LU, durant une conversation. Ces propriétés incluent la classe de service.
Un noeud de fonction désigne une application (ou un ensemble d'applications) permettant de fournir à une LU des fonctions utilitaires de base. Les fonctions délivrées comprennent la manipulation d'informations annexes, le traitement du démarrage d'applications et les processus de fermeture d'application. Des noeuds de fonction d'OS/2 sont fournis avec Communications Manager (CM) ou Communications Manager/2 (CM/2).
Le mot "partenaires" désigne deux applications CPIC qui échangent des données grâce à des conversations CPIC.
Les conversations CPIC peuvent être en duplex intégral, ce qui signifie qu'à une période quelconque d'une conversation CPIC, l'un des partenaires a le droit d'envoyer des données, tandis que l'autre se trouve en état d'en recevoir. Lorsqu'une application se trouve en état Réception, elle peut émettre une demande d'envoi de données lorsque cela est nécessaire. Le partenaire reçoit alors la notification de cette requête, tandis que l'application demandeuse reçoit une notification dans le paramètre StatusReceived.
Le nom de destination symbolique (SDN) est un nom de configuration CPIC utilisé par Communications Manager/2, qui permet à une application d'indiquer l'ensemble des attributs requis pour une demande d'attribution de conversation.
Une session désigne une connexion logique entre deux LU. Les LU communiquent entre elles par l'intermédiaire de sessions.
Il s'agit des informations d'initialisation utilisées par CPIC lors des tentatives d'établissement de conversations. Les informations annexes portent sur le nom de la LU partenaire, le nom de mode et le nom du programme de transactions (TP). Ces informations sont configurées avant que la conversation ne soit établie.
Remarque : Les informations annexes sont référencées par un nom de destination symbolique.
Un réseau SNA st un réseau logique composé de plusieurs LU.
Le niveau de synchronisation indique le degré de synchronisation qui caractérise une conversation CPIC. Les niveaux de synchronisation peuvent être les suivants :
SYNC_POINT indique que votre application prend en charge les opérations de récupération SAA intégrales, telles que les notifications Take Commit et Take Backout.
Remarque : La prise en charge de SYNC_POINT n'est pas assurée sur OS/2.
Le programme de transactions (TP) est une application utilisant des commandes CPIC ou APPC pour participer à une conversation.
Le nom de programme de transactions est le nom d'une application de transaction, qui est spécifié dans les informations annexes. Suivant le système d'exploitation utilisé, le nom du programme de transactions peut définir une entrée de table pour appliquer les services du noeud de la LU cible. Cette table est utilisée pour rechercher les informations nécessaires au lancement du programme de transactions.
Le chapitre ci-dessous illustre brièvement l'exemple d'une méthode utilisée lorsqu'une application lance une conversation avec une autre application.
TSD Script ne permet pas de contrôler directement la taille allouée à l'espace mémoire. Les développeurs n'ont donc plus à se soucier de la taille des enregistrements qu'ils déclarent.
Bien que cette caractéristique soit jugée intéressante pour un langage de quatrième génération, certaines difficultés peuvent voir le jour lors du travail avec les applications CPIC. Ces dernières envoient et reçoivent des mémoires tampons caractérisées par une taille et un format spécifiques. Une application partenaire peut utiliser des formats d'enregistrement différents de ceux de l'application locale, tels que des nombres entiers non reconnus par Intel ou des chaînes de caractères EBCDIC.
Les fichiers de description de données (ou fichiers DDF) offrent la possibilité de définir différentes tailles de mémoire tampon. Un fichier DDF définit le format exact d'une mémoire tampon contenant les données transmises et précise le mode de transcription ou de conversion du format. La boîte à outils du développeur de TSD se sert de ces fichiers DDF comme de "filtres" avec les tampons entrants et sortants d'une application CPIC.
La structure fondamentale d'un fichier DDF est la suivante :
-- Les deux tirets indiquent un commentaire de fin de ligne. -- La première section concerne les partenaires. *PARTNER -- types de conversion de caractères EBCDIC=TRUE -- ordre des octets entiers NON_INTEL=TRUE -- table de conversion de caractères. A défaut, la boîte à outils du développeur -- utilise la table AE de CM/2. Cette table par défaut peut s'avérer -- insuffisante pour vos besoins (par exemple, elle -- convertit les espaces en x'00'). Si vous souhaitez -- utiliser une table de conversion plus normale, configurez -- le nom du fichier de table ACSGTAB.DAT, fourni avec -- CM/2. Ensuite, attribuez à CUSTOM_CONVERT la valeur TRUE. CUSTOM_CONVERT=TRUE -- Cette section concerne les zones. Elle sert à décrire -- chaque zone de l'enregistrement, ainsi que le mappage et -- la conversion des octets. Cette section indique essentiellement -- l'aspect que doit avoir le tampon de données juste avant sa -- réception (avant conversion), ou juste avant son envoi -- (après conversion). *FIELDS -- Fieldname Type ByteWidth SendUnknowns? Default name CHAR 20 FALSE street CHAR 20 TRUE age INTEGER 20 TRUE birthDate CCYYMMDD 8 FALSE
Dans cet exemple, l'application partenaire est exécutée sur une machine EBCDIC à nombres entiers non-Intel (par exemple, IBM System 370). L'enregistrement envoyé est déclaré comme suit dans TSD Script :
SomeRecordName IS RECORD name :STRING; street :STRING; age :INTEGER; birthDate :DATE; description:STRING; END;
La zone réservée à la description n'est pas incluse dans le fichier DDF, ce qui implique que le transfert de cette zone n'a pas lieu lors des communications CPIC.
Cette section d'un fichier DDF contient la description du type de machine de l'application partenaire. Elle débute par le texte *PARTNER. La section Partner indique les types de conversion de données employés par la boîte à outils du développeur de TSD. Par exemple, la définition de la valeur EBCDIC=TRUE signifie que la boîte à outils convertit toutes les chaînes de caractères, depuis ou vers EBCDIC, lors des communications avec l'application partenaire.
Il convient de définir les attributs ci-dessous dans la section Partner. Tout attribut non défini suppose que la valeur par défaut est prise en compte.
Cette section du fichier DDF définit les zones et types de zones qui doivent être compressés et décompressés dans les tampons de données CPIC. Cette section de fichier DDF commence par la ligne contenant le mot "*FIELDS". Chacune des lignes de la section Fields correspond à une zone d'enregistrement transférée par TSD Script. Ces lignes adoptent le format suivant :
{fieldname} {fieldtype} {bytewidth} {sendunknowns?} {default}
Les espaces servent à différencier les colonnes. Celles-ci sont définies conformément à la liste ci-dessous :
La commande $INCLUDE simplifie la configuration d'un fichier DDF. Cette commande permet de "relier" dynamiquement d'autres fichiers. Lorsque la commande $INCLUDE est détectée par la boîte à outils du développeur de TSD, celle-ci charge le fichier DDF simplifié et ajoute ses définitions de zones dans le fichier DDF en cours.
La commande $INCLUDE peut être incorporée en tout point de la section Fields. Le format de la commande $INCLUDE est le suivant :
$INCLUDE({DDFname})
Lorsque le fichier ne se trouve pas dans le répertoire en cours, la boîte à outils du développeur de TSD recherche le chemin DPATH de ce fichier. Lorsque ce dernier est introuvable, une erreur est renvoyée par la boîte à outils du développeur de TSD.
La commande $SIZEOF exécute automatiquement un nouveau calcul de la taille des fichiers inclus. Il n'est pas nécessaire de les recompter manuellement lorsque de nouvelles zones sont ajoutées.
Les commandes $SIZEOF et $INCLUDE sont utilisées pour les cas particuliers, tels que la configuration d'une mémoire tampon vectorisée. Elles peuvent être utilisées en combinaison, comme suit :
*PARTNER EBCDIC =TRUE NON_INTEL =TRUE CUSTOM_CONVERT =TRUE *FIELDS GDS1310 INT 2 TRUE 4880 GDS1311LEN INT 2 TRUE $SIZEOF(1311.DDF) + 2 $INCLUDE(1311.DDF) GDS1549LEN INT 2 TRUE $SIZEOF(1549.DDF) + 2 $INCLUDE(1549.DDF) DataLen INT 2 TRUE $SIZEOF(RTRNDATA.DDF) + 2 $INCLUDE(RTRNDATA.DDF)
Les types reconnus pour le traitement du fichier DDF sont les suivants :
Plusieurs détails doivent avoir été portés à votre connaissance avant de commencer l'écriture d'applications CPIC pour OS/2. Ces dernières peuvent, dans certains cas, être regroupées en fonction du type de services de noeud disponibles sur votre système.
Compte tenu de la manière dont le noeud de services définit les programmes de transactions en vue de recevoir les demandes de connexion, il est impossible de définir une application CPIC pour OS/2 en tant que programme de transactions de service SNA. Vous devez tenir compte des étapes suivantes, qui résument la méthode de traitement des demandes de connexions :
Si vous souhaitez configurer un programme de transactions pour plusieurs applications TSD Script, vous devez faire appel à une procédure spéciale. Communications Manager/2 vous autorise uniquement à définir kml.exe comme variable PATH et nom de ficher d'application OS/2 pour une définition de programme de transactions. Pour un autre programme, vous devez créer un fichier de commande OS/2 comprenant les commandes suivantes :
SET APPCTPN={nom de votre programme de transactions} START /C KML /U {chemin d'accès à la base de connaissances} {nom de la base} EXIT
Communications Manager/2 permet à un processus CPIC unique d'accepter des conversations multiples. De plus, une application CPIC ne peut exécuter qu'une seule commande Initialize tant qu'aucune commande Accept n'a encore été lancée.
La présente section expose brièvement le procédé de création d'une application CPIC simple. Cette application est conçue pour effectuer un transfert de fichier.
Pour illustrer les avantages de CPIC, deux exemples de modules sont présentés. L'application est créée dans le premier exemple de module. Dans le deuxième exemple, certains changements mineurs ont été apportés à l'application afin d'en améliorer les performances.
L'étude du cas de cet exemple suppose à plusieurs égards que vous maîtrisez le fonctionnement de CPIC, de Communications Manager/2 et des applications de communications en général. Il est par exemple implicite que vous possédez de bonnes connaissances de l'utilitaire CMSETUP de Communications Manager/2.
Vous devez en premier lieu examiner l'application partenaire développée en langage REXX.
Le nom de l'application partenaire REXX est RCV.CMD. Il s'agit essentiellement d'une application qui reçoit des données (en les enregistrant dans une variable indicée), jusqu'à ce qu'un paramètre d'état indique que l'application peut dorénavant envoyer des données.
L'échantillon de code ci-dessous fournit des explications détaillées sur l'application.
/* RCV.CMD */ /* Reçoit des chaînes de données en les regroupant par tampons. /*Après la*/ /* réception, le tampon de données est renvoyé. */ /* Commandes CPIC utilisées : CMACCP */ /* CMCFMD */ /* CMDEAL */ /* CMRCV */ /* CMSEND */
/* constantes couramment utilisées */ CM_OK = 0 /* état reçu */ CM_SEND_RECEIVED = 1 CM_CONFIRM_RECEIVED = 2 /* données reçues */ CM_NO_DATA_RECEIVED = 0
MaxLength = 257; BufferLen = 0; FileBuffer.0 = 0; 'CPICREXX'
address cpicomm 'CMACCP Conv_ID RetC'; if \(RetC = CM_OK) then do SAY 'ACCP = 'Retc end;
'CMRCV Conv_ID Data MaxLength DataReceived ReceivedLength StatusRecvd ReqToSendRecvd Retc'; if \(RetC = CM_OK) then do SAY 'RCV = 'Retc end;
do while (RetC = CM_OK) & (StatusRecvd \= CM_SEND_RECEIVED) if (DataReceived \= CM_NO_DATA_RECEIVED) then do /* SAY Data */ FileBuffer.0 = FileBuffer.0 + 1; i = FileBuffer.0; FileBuffer.i = Data; end; if (StatusRecvd = CM_CONFIRM_RECEIVED) then do 'CMCFMD Conv_ID RetC'; end; 'CMRCV Conv_ID Data MaxLength DataReceived ReceivedLength StatusRecvd ReqToSendRecvd Retc'; if (RetC \= CM_OK) then do SAY 'RCV = 'Retc end; end;
SAY 'Fichier de retransmission'
DO i = 1 TO FileBuffer.0 BufferLen = LENGTH(FileBuffer.i); Data = FileBuffer.i; 'CMSEND Conv_ID Data BufferLen ReqToSendRecvd RetC'; if (RetC \= CM_OK) then do SAY 'SND = 'Retc end; END; 'CMDEAL Conv_ID RetC'; address cmd 'EXIT'
Cette application consiste à lire un fichier texte et à transmettre chacune des lignes à une application partenaire. Une fois le transfert de fichier terminé, l'application commence par recevoir à nouveau le fichier, puis affiche les lignes une par une dans une fenêtre.
En commencençant à l'étape 3, vous définissez une entrée dans la table des informations annexes de Communication Manager/2. La table d'informations annexes est utilisée lors de l'initialisation d'une conversation. L'initialisation s'accomplit de la manière suivante :
En appliquant cette méthode, les applications CPIC peuvent être écrites sans contenir d'informations figées dans le code ni spécifiques au site. Cette méthode permet également de standardiser l'accès de toutes les applications CPIC à ce type d'informations.
En commençant à l'étape 8, une définition de programme de transactions est créée. Cette entrée indique la manière dont le noeud de services doit démarrer un programme de transactions particulier.
Lorsqu'une conversation a été attribuée, la LU responsable de la demande d'attribution envoie le nom du programme de transactions souhaité vers le système du noeud de services de la LU cible. Celui-ci contrôle que le nom du programme de transactions a été défini sur le système. Si tel est le cas, les services de noeud se conforment aux instructions concernant le mode de démarrage du programme de transactions. Si l'application peut être démarrée, le lancement est effectué (lorsque le gestionnaire de connexions est configuré pour le programme de transactions). Le programme de transactions lance alors la commande CPICAccept. La LU demandeuse reçoit une confirmation de bonne exécution, et la conversation est lancée.
Pour cette application REXX, un processeur de commandes OS/2 est démarré (CMD.EXE). La chaîne de paramètres indique à CMD.EXE de quitter l'application lorsque l'exécution de la commande a abouti (/C), en précisant la commande à exécuter (RCV.CMD).
La partie suivante de l'étude de cas consiste à exécuter le fichier RCV.CMD à partir d'une ligne de commande OS/2.
Cette commande permet d'envoyer alternativement le fichier source entre les deux applications, puis d'afficher les résultats de l'opération dans une fenêtre.
Ce double transfert peut nécessiter un temps d'exécution assez long. La durée d'exécution est affichée en bas de la liste de fichiers.
Par ailleurs, vous pouvez noter les numéros de ligne correspondant à chaque ligne du fichier. Ces numéros sont transmis dans les deux directions de transfert, pour chaque ligne du fichier de texte.
A la suite de la présente section de lignes numérotées figure un descriptif du contenu de ce fichier.
1 2 KNOWLEDGEBASE FILESND; 3 4 ROUTINES 5 PROCEDURE DoConversation(VAL Args:List of String); 6 (* sdn, infile *) 7 8 9 PRIVATE 10 11 CONSTANTS 12 CPIC_SUCCESS IS 1; 13 14 TYPES 15 FileRec IS RECORD 16 LineNbr:Integer; 17 Buff:String; 18 END; 19 20 ROUTINES 21 22 FUNCTION RcvData(REF w:WINDOW, VAL Conv:Conversation) :INTEGER IS 23 VARIABLES 24 totalBuff :FileRec; 25 dataRcvd :integer; 26 statRcvd :integer; 27 reqTSRcvd :integer; 28 rc :integer; 29 ACTIONS 30 IF (not(Known(w))) THEN 31 WinCreateScrollWindow($DESKTOP,w, 32 $NullHandler, 1,1,67,7, 'FileSnd','', 0, $WinBorder+ $WinTitle+ $WinHScroll+ $WinVScroll+ $WinSysMenu+ $WinResize); END; 33 REPEAT 34 rc := CPICReceive(Conv,'FILEREC.DDF', totalBuff,DataRcvd, StatRcvd,ReqTSRcvd); 35 IF (rc > 0) THEN 36 IF ((StatRcvd = $CPICConfirmReceived) or 37 (StatRcvd = $CPICConfirmSend Received)) THEN 38 rc := CPICConfirmed(Conv); 39 END; 40 totalBuff.buff := StrTrim (totalBuff.buff); 41 WinWriteLn(w,totalBuff.lineNbr:5&' :'&totalBuff.buff); 42 END; 43 UNTIL ((rc <> 1) OR ((StatRcvd = $CPICSendReceived) OR 44 (StatRcvd = $CPICConfirmSend Received))); 45 Exit(rc); 46 END; -- RcvData 47 48 49 --------------------------------------------- 50 -- Description : Lit le fichier spécifié, en transmettant chaque ligne via CPIC 51 -- vers le partenaire spécifié dans le nom de destination symbolique concerné. 52 --------------------------------------------- 53 PROCEDURE DoConversation(VAL Args:List of String) IS 54 VARIABLES 55 Conv :Conversation; 56 fRec :FileRec; 57 ReqTSRcvd:INTEGER; 58 rc :INTEGER; 59 inf :FILE; 60 w :WINDOW; 61 t1,t2 :TIME; 62 ACTIONS 63 t1 := $NOW; 64 IF (ListLength(Args) <2) THEN WinMessageBox($DESKTOP,Ò