**Description d'AS Java**

**APERÇU DE LA LEÇON**

Cette leçon traite du fonctionnement du serveur d'applications SAP NetWeaver Java (AS Java). Les
processus sont introduits et expliqués dans leur fonctionnement.

Cette leçon présente les processus de SAP NetWeaver AS Java. Les différentes tâches des différents
processus sont introduites. Après cette leçon, les participants devraient connaître les mécanismes et
processus de base dans SAP NetWeaver AS Java. Il ne s'agit pas de décrire en détail toutes les
fonctions différentes.

**EXEMPLE D'ENTREPRISE**

Pour consolider vos paysages de systèmes SAP hétérogènes, votre entreprise a décidé de migrer les
applications Java EE, qui étaient précédemment exécutées sur un serveur Java EE tiers, vers AS Java.

**OBJECTIFS DE LA LEÇON**

Après avoir terminé cette leçon, vous serez capable de :

- Décrire le traitement des demandes utilisateur dans les systèmes SAP basés sur AS Java

- Répertorier les processus d'AS Java et expliquer leur utilisation

- Répertorier les principaux outils pour l'administration d'AS Java et en expliquer l'utilisation

**Définition des termes**

AS Java implémente un serveur Java EE. Le tableau suivant montre les dépendances de version :

Tableau 2 : Dépendances de version d'AS Java

AS Java Edition Enterprise JDK SAP JVM

7.50 Java EE 5 8 (1.8.0) 8.1

7.20, 7.30, 7.31, 7.40 Java EE 5 6 (1.6.0) 6.1

7.10, 7.11, 7.20 Java EE 5 5.0 (1.5.0) 5.1

7.00, 7.01, 7.02, 7.03 J2EE 1.3 1.4.2 4.1

6.40 J2EE 1.3 1.4.2 4.1

En ce qui concerne l'explication :

SAP NetWeaver

Plateforme d'intégration et d'application de SAP

AS Java

SAP NetWeaver AS Java, partie du serveur d'applications SAP NetWeaver

Edition Enterprise

Plateforme Java officielle, Edition Entreprise : Spécifications pour le développement et l'exploitation

d'applications spécifiques à l'entreprise

JDK

Kit de développement Java : Kit de développement logiciel développé par Sun/Oracle pour les
applications Java

JRE

Environnement d'exécution Java : Environnement d'exécution pour les applications Java

SAP JVM

Machine virtuelle Java SAP : JVM/JDK certifiée fournie par SAP pour les applications SAP

**Traitement des demandes dans AS Java**

Le traitement d'une demande utilisateur dans AS Java, tel qu'indiqué dans la figure suivante,
implique différents processus sur les trois couches (présentation, application et base de données).
Un navigateur web est l'interface utilisateur standard pour AS Java. Une demande d'utilisateur pour
AS Java est généralement une demande HTTP(S) reçue par le ICM. Le processus ICM transmet les
demandes de traitement à l'un des processus serveur de son serveur d'application.

Le traitement réel a lieu dans le processus serveur, où l'utilisateur ayant envoyé la demande se voit
généralement attribuer le même processus serveur pour la demande suivante.

Les processus serveur d'AS Java sont également appelés nœuds. Tous les processus d'AS Java
associés au schéma de base de données forment le cluster Java. Contrairement aux processus de
travail de l'AS ABAP, les processus serveur de l'AS Java sont multithreadés. Cela signifie qu'un
processus serveur est constitué de nombreux threads et qu'une demande peut être traitée dans
chaque thread. Un processus serveur peut donc traiter de nombreuses demandes d'utilisateurs en
parallèle.

Pour traiter les demandes d'utilisateurs, il est souvent nécessaire de lire des données du schéma Java
de la base de données ou d'écrire dedans. Pour ce faire, chaque processus serveur est connecté
plusieurs fois au schéma Java de la base de données via un pool de connexions (pool de DB).

Une fois le traitement terminé, le résultat du traitement des processus serveur est renvoyé au
navigateur web via le ICM.

Les tampons contribuent à accélérer le traitement des demandes d'utilisateurs. Cela signifie que les
données n'ont pas besoin d'être lues depuis la base de données à chaque fois qu'elles sont
nécessaires, mais qu'elles peuvent être appelées très rapidement à partir du tampon. Chaque
processus serveur a son propre tampon.

Dans AS Java, les processus serveur s'exécutent dans une machine virtuelle Java (JVM). La JVM se
charge indépendamment de la gestion de la mémoire. Ainsi, les programmes Java requis (classes)
sont automatiquement chargés dans la mémoire JVM et supprimés lorsque cela n'est plus nécessaire
(collecte des déchets). Contrairement à l'AS ABAP, il n'y a donc pas de tampon de programme. Le
tampon dans la figure "Traitement des demandes dans AS Java" est le tampon de table. Le
développeur Java décide si le contenu de la table est mis en tampon ou non (tout comme dans l'AS
ABAP). Une différence centrale entre l'AS ABAP et l'AS Java est donc que de nombreuses
informations sont conservées localement pour chaque processus serveur dans l'AS Java, tandis que le
plus possible est conservé dans la mémoire partagée de l'instance dans l'AS ABAP.

Les processus serveur sont divisés en différents modules fonctionnels appelés gestionnaires et
services. Les gestionnaires forment le Runtime Enterprise Java. Le Runtime Enterprise Java fournit les
fonctions de base essentielles d'AS Java. Il est également connu sous le nom de noyau.

En collaboration avec les interfaces et les bibliothèques, les services sont appelés Composants du
Moteur Java EE. Les Composants du Moteur Java EE fournissent des interfaces de programmation
(API) aux applications ; les applications peuvent ensuite utiliser ces API pour accéder aux fonctions
d'AS Java.

Dans le cas d'une demande HTTP, le processus ICM utilise un gestionnaire Java EE pour transférer la
demande à un processus serveur de ce serveur d'application.

Le gestionnaire de cluster du processus serveur reçoit la demande et la transmet au service

fournisseur HTTP. Dans le service conteneur web, la logique de présentation de l'application est
ensuite traitée. Le service de conteneur web assure le traitement des servlets et des pages
JavaServer (JSP). La logique de la structure commerciale de l'application est traitée sous forme de
beans EJB dans le service de conteneur EJB. Si, dans le traitement de la demande, des données de la
base de données sont nécessaires, le service de connecteur JDBC est utilisé pour établir une
connexion avec la base de données, et les données sont demandées là-bas. Si le même contenu de
table a déjà été interrogé par ce processus serveur, le contenu du tampon de table peut être
interrogé au niveau de l'application (si la mise en tampon est autorisée pour la table).

La réponse au navigateur web en utilisant HTTP est ensuite renvoyée de la même manière.

Traitement transactionnel dans AS Java

Les explications suivantes sont considérablement simplifiées. De plus, les procédures habituelles
dans l'environnement SAP sont expliquées ici. Certaines d'entre elles divergent de la norme Java EE
ou la complètent. Il devrait être clair pour les participants qu'AS Java est également capable
d'opérations transactionnelles, mais qu'il existe différentes différences par rapport à AS ABAP.

Le concept ACID a été implémenté dans AS Java de la même manière que dans AS ABAP. Dans AS
Java, le Service de Transaction est responsable de la gestion des transactions. Les deux normes Java
EE, Java Transaction API (JTA) et Java Transaction Service (JTS), sont mises en œuvre en utilisant le
Service de Transaction. Les applications (développeurs d'applications) peuvent utiliser le Service de
Transaction Java avec l'interface JTA.

Outre les transactions JTA, les développeurs AS Java peuvent également utiliser des transactions
locales pour des applications très simples. Cependant, SAP recommande d'utiliser la JTA.

La norme Java EE vous permet de traiter des données sur plusieurs bases de données
simultanément. Dans des termes plus généraux, elles sont appelées gestionnaires de ressources (par
exemple, une base de données, un système d'information d'entreprise, etc.) dans l'environnement
Java EE. Par conséquent, la JTA permet également les transactions distribuées. Le commit en deux
phases (2PC) est utilisé pour valider de telles transactions sur les gestionnaires de ressources
distribuées. SAP déconseille la conservation de données distribuées pour une application. Ces
options ne sont pas disponibles dans AS ABAP.

Dans la norme Java EE, une grande partie de la mise en œuvre de la logique transactionnelle est
laissée à la base de données respective utilisée. Ainsi, une transaction au niveau de l'application
correspond souvent exactement à une transaction de base de données dans la norme Java EE. La
figure suivante illustre la corrélation à l'aide d'une application JSP comme exemple.

L'objectif de cette illustration est d'expliquer ce qui suit : Dans le navigateur, l'utilisateur
voit le HTML généré par une page JSP et y apporte des modifications. Il peut également y avoir des
changements dans l'interface utilisateur (ils passent à une page d'onglets) et l'utilisateur apporte
encore plus de modifications (toujours sur la même page JSP). Ensuite, l'utilisateur enregistre ses
saisies. C'est-à-dire que les modifications sont renvoyées au processus serveur et la logique du
programme garantit que les données sont persistées et que la transaction est validée. Ensuite,
l'utilisateur reçoit le HTML d'une autre page JSP dans le navigateur.

Pour simplifier les choses, nous n'avons pas utilisé de composants EJB ni de Java Web Dynpro ici. Par
exemple, une application Web Dynpro enregistre d'abord les saisies d'un utilisateur dans le contexte,
c'est-à-dire dans la mémoire de travail du processus serveur. Les données sont ensuite rendues
persistantes dans une transaction de base de données tout en étant enregistrées dans l'interface
utilisateur.
Dans AS Java, les modifications et les entrées dans l'interface utilisateur (dans le navigateur Web) ne
sont pas immédiatement rendues persistantes dans la base de données. Lorsque l'utilisateur
enregistre ses saisies, la transaction Java est achevée immédiatement et les données sont rendues
persistantes dans une transaction de base de données. Ainsi, une transaction Java consiste en une
transaction de base de données.

Bien sûr, en cas de transactions distribuées sur plusieurs gestionnaires de ressources, plusieurs
transactions de base de données ont lieu, mais SAP ne recommande pas cette approche.

Persistance

SAP a créé le framework Open SQL for Java pour AS Java. Par conséquent, les développeurs
d'applications Java ont accès à diverses techniques de programmation indépendantes de la base de
données, ainsi qu'à des fonctions importantes pour améliorer les performances et la résolution des
problèmes.

La figure ci-dessus est une représentation simplifiée et doit être interprétée et présentée aux
participants comme suit : SAP a créé le framework Open SQL for Java. Le cœur du framework est le
moteur Open SQL, qui fournit diverses fonctions au-delà de la norme Java EE, telles que la
vérification des instructions SQL envoyées et le cache de table. Le framework Open SQL Java est
utilisé, d'une part, pour se connecter à la base de données (pilote de la base de données) et, d'autre
part, pour fournir aux développeurs diverses techniques de programmation Open SQL, qu'ils peuvent
utiliser pour écrire un code portable et utiliser les fonctions du framework. Les techniques de
programmation qui génèrent un code portable sont affichées en vert. Ici, portable signifie que vous
pouvez changer de fournisseur de base de données et que l'application fonctionne toujours.

Si le développeur décide de programmer en SQL natif, l'application ne sera pas portable et il perdra
la fonction du cache de table. Néanmoins, d'autres fonctions du moteur Open SQL, telles que la trace
SQL, peuvent toujours être utilisées.

Si le programme Java doit être portable, c'est-à-dire fonctionner avec une base de données autre que
celle utilisée initialement, les développeurs peuvent choisir entre Open SQL/JDBC, Open SQL/SQLJ,
EJB (Enterprise JavaBeans) et JDO (Java Data Objects). Si les développeurs utilisent SQL natif dans le
programme, ils perdent la portabilité et ne peuvent pas utiliser le cache de table du framework Open
SQL Java.

En cas de questions de la part d'experts en Java EE : La variante EJB fait référence aux Entity Beans
avec une gestion de persistance par le conteneur.

Outre les caches de table, le framework Open SQL Java offre également la mise en cache des
instructions (statement pooling) et la trace SQL. La mise en cache des instructions signifie que les
instructions SQL fréquemment utilisées peuvent être mises en cache. La trace SQL permet de
consigner les instructions SQL envoyées à la base de données à des fins de dépannage ou d'analyse
des performances. Les deux fonctions sont également disponibles lorsque les développeurs utilisent
le SQL natif.

Le service de connexion JDBC est utilisé pour définir quels pilotes de base de données, c'est-à-dire
quelles interfaces Java, sont disponibles pour les développeurs. Le paramètre par défaut de SAP est
Open SQL, de sorte que le framework Open SQL Java de SAP est utilisé. Le framework est également
utilisé dans le paramètre SQL natif (mais sans cache de table et sans vérification de la portabilité).
Avec le paramètre SQL du fournisseur, les développeurs ne peuvent utiliser que les interfaces natives
du fournisseur de base de données et perdent toutes les fonctions du framework SAP. La différence
entre le SQL natif et le SQL du fournisseur réside donc dans la perte de fonctions supplémentaires.
Du point de vue du développeur, une instruction SQL spécifique à la base de données (SQL natif) est
exécutée dans les deux cas.

Avec AS Java 7.10, Open SQL/SQLJ, EJB (Enterprise JavaBeans) et JDO (Java Data Objects) ne sont pris
en charge que pour la compatibilité descendante et ne devraient donc pas être utilisés.

Gestion des Verrous (Lock Management)

Le concept de verrouillage de la base de données est utilisé dans la norme Java EE. Ainsi, si les
développeurs d'applications veillent à mettre en œuvre des accès à la base de données indépendants
de la base de données, l'application sera portable mais réagira de manière sémantiquement
différente sur différentes plates-formes de base de données. Pour cette raison et pour améliorer les
temps de réponse, SAP a introduit le concept du service d'enrôlement, analogiquement à AS ABAP.

Si un utilisateur souhaite modifier l'accès à des données, le processus serveur en cours d'exécution
demande un verrou (pour ce faire, le développeur de l'application doit programmer cette demande
explicitement).

Le développeur de l'application utilise l'interface du service de verrouillage de l'application pour

demander un verrou logique.

La demande est transmise au serveur d'enrôlement via le service d'adaptation de verrouillage et le

gestionnaire de verrouillage. Le serveur d'enrôlement vérifie alors s'il est possible de générer un
nouveau verrou, c'est-à-dire s'il y a une collision avec des verrous qui ont déjà été définis. Si un
verrou peut être défini, le processus de travail en mode dialogue le crée et l'utilisateur (propriétaire
du verrou) reçoit la clé du verrou.

Lorsque le verrou est demandé, le système vérifie si le verrou demandé entre en conflit avec des
entrées existantes dans la table des verrous. Si la table des verrous contient déjà des entrées
correspondantes, la demande de verrouillage est refusée. Le programme d'application peut ensuite
informer l'utilisateur que l'opération demandée ne peut pas être exécutée actuellement.

Administration de AS Java
Il existe également divers outils d'administration disponibles pour AS Java. Certains de ces outils sont
répertoriés dans la figure suivante.

Lors de la présentation de ce graphique, concentrez-vous sur l'Administrateur SAP NetWeaver et la

console UME. L'outil Config Tool est mentionné à des fins d'exhaustivité et est catégorisé comme
outil expert car sa présentation détaillée n'entre pas dans le cadre de ce cours. Néanmoins, les
participants devraient avoir entendu les noms de ces outils mentionnés au cours de ce cours.

L'Administrateur SAP NetWeaver combine les outils d'administration et de surveillance les plus
importants pour les systèmes AS Java dans une interface utilisateur basée sur un navigateur. Pour AS
Java, l'Administrateur SAP NetWeaver marque le passage de divers outils experts différents à une
solution intégrée, simple et claire. En plus de cela, l'Administrateur SAP NetWeaver complète
l'intégration des sources de données pour la surveillance. Pour démarrer l'Administrateur SAP
NetWeaver, vous pouvez entrer l'URL suivante dans le navigateur Web : [Link]
d'hôte>:<numéro de port>/nwa.

- <nom d'hôte> : Le nom de serveur entièrement qualifié sur lequel AS Java est installé.

- <numéro de port> : Le port HTTPS de l'ICM (Internet Communication Manager). Syntaxe :

5<numéro d'instance Java>01. Si le numéro de l'instance Java est par exemple 91, le numéro de port
sera 59101. Le serveur d'application que vous utilisez pour appeler l'Administrateur SAP NetWeaver
est sans importance. Il peut être utilisé pour administrer l'ensemble du système AS Java.

L'Administrateur SAP NetWeaver est divisé en les domaines fonctionnels suivants :

Domaines fonctionnels de l'Administrateur SAP NetWeaver

- Disponibilité et performance (par exemple, vue d'ensemble du système, surveillance des

ressources, surveillance des processus)
- Opérations (par exemple, gestionnaire d'applications, démarrage et arrêt)

- Configuration (par exemple, licences, propriétés du système AS Java, configuration des journaux)

- Analyse des erreurs (par exemple, informations système SAP, chargeur de classes Java, visualiseur)

- SOA (par exemple, destinations, fournisseur JCo RFC)

Conseil :

Pour travailler avec l'Administrateur SAP NetWeaver, l'utilisateur du système doit disposer des
autorisations suivantes :

- NWA_READONLY (autorisation de lecture)

- NWA_SUPERADMIN (autorisation d'écriture pour le démarrage et l'arrêt, les modifications de

configuration, etc.)

L'Administrateur SAP NetWeaver est disponible dans le cours SAPTEC et l'instructeur peut l'appeler
via l'URL [Link] (91 = numéro d'instance). Les utilisateurs TRAIN-##
devraient avoir les autorisations nécessaires pour accéder à l'Administrateur SAP NetWeaver. Si vous
souhaitez présenter l'Administrateur SAP NetWeaver dans le cadre du cours, assurez-vous de vous
familiariser avec ses fonctions avant le début du cours.

Dans AS Java, le moteur de gestion des utilisateurs (UME) fournit les fonctions nécessaires pour gérer
les enregistrements de maître d'utilisateurs. Vous pouvez utiliser l'UME pour mettre en place et
exploiter des concepts d'utilisateurs et d'autorisations pour AS Java. L'UME dispose de sa propre
console d'administration pour la gestion des utilisateurs (console UME, voir la figure ci-dessus). Elle
permet à l'administrateur d'effectuer les tâches courantes d'administration des utilisateurs, telles
que la création d'utilisateurs et de groupes, l'attribution de rôles et d'autres actions. Les paramètres
de sécurité peuvent être utilisés pour définir des politiques de mot de passe, telles que la longueur
minimale du mot de passe et le nombre de tentatives de connexion incorrectes avant qu'un
utilisateur ne soit verrouillé.

La console UME fournit à AS Java des fonctions qui correspondent aux transactions AS ABAP SU01 et
PFCG. Vous pouvez accéder à la console UME depuis la page de démarrage AS Java [Link]
d'hôte entièrement qualifié>:5$$01/) via le lien de gestion des utilisateurs. Pendant le cours SAPTEC,
les participants devraient disposer des autorisations nécessaires pour accéder à l'UME (ceci peut être
fait en attribuant le rôle PFCG vide SAP_J2EE_ADMIN, qui correspond au groupe UME du même nom,
et qui régit les autorisations Java pertinentes).

Conseil :

Soyez clair sur le fait que si un système SAP est basé sur AS ABAP et AS Java, les données utilisateur
sont stockées dans les tables AS ABAP et la console UME utilise ces informations. Dans ce cas, la
console UME n'est pas configurée pour stocker les enregistrements de maître d'utilisateurs (cela se
ferait dans la transaction SU01 d'AS ABAP) mais pour émettre des autorisations Java aux utilisateurs
individuels (via les rôles UME). Dans les systèmes SAP sans AS ABAP, en revanche, il est également
possible de créer des utilisateurs avec la console UME.

Note :

L'Administrateur visuel est une interface graphique (GUI) qui permet l'administration de tous les
éléments du cluster Java (répartiteur Java, serveur Java) et de tous les modules qui y fonctionnent. Il
permet la surveillance à distance et la configuration à distance du gestionnaire, des services, des
interfaces et des bibliothèques Java, le tout dans une seule interface. Cet outil n'est plus disponible à
partir de AS Java 7.10. L'Administrateur visuel a été remplacé par l'Administrateur SAP NetWeaver.

L'outil Config Tool permet la configuration hors ligne des éléments de cluster Java. Il permet d'ajouter
et de configurer les propriétés des éléments individuels du cluster Java.

Indiquez que l'outil Config Tool est un outil expert qui n'est pas couvert dans le cadre de cette leçon.
L'outil Config Tool est décrit en détail dans le cours de suivi ADM800 - Administration AS Java.

Conseil :

Pour plus d'informations, consultez la documentation en ligne disponible sur le portail d'aide SAP
([Link] et le cours SAP : ADM800 : AS Java - Administration.