# Migration SoftwareAG 10.15

***
**Question : utilisation de dat ?**
**Doit on installer les fix avant migration sur l'ancien serveur ?**

## Integration server

- vérifier l'espace dispo
- Installer nouveau produit (template composite pour nous)
- Preparer l'ancienne installation
>- Lancer et l'is et l'um et vérifier que cest ok
>- vérifier que les jars sont compatibles avec la nouvelle version
>- Couper trigger
>>- Pannel Admin IS server>Quiesce -> time to occur a au moins 1 min
>>- Aller dans Messaging > webMethods Triggerss : vérifier que le champ "current queue count" est bien à "0" pour chaque trigger
>>- Aller dans Messaging > webmethods setting : vérifier que CSQ count est à 0 pour Universal Messaging connection alias
>>- Aller dans Messaging > JMS Setting : vérifier CQS count est à "0" pour chacue JMS connection alias
>- Si on a des packages qui commencent par Wm alors aller dans "new_SoftwareAG_directory/IntegrationServer/bin/migrate" et ouvrir packages.cnf et ajouter la ligne
- *<value name="WmExemple">WmExemple</value>*
>- Quand on migre une is on doit aussi migrer My WM Server
- ???????????? Active transfer cest quoi
>- Eteindre l'ancienne IS
>- **Migrer database component**
>- Création du zip de l'ancien produit
- *Specify the location of the Java Archive tool in the JAVA_HOME and PATH system variables on the machine that hosts the old product installation. The tool is located in the Software *AG_directory/jvm/jvm/bin directory. On some systems, the lower-level jvm directory name includes additional information, such as /jvm/jvm160_32, or /jvm/jvm170, or /jvm/jvm_64.*
>- Bouger les logs pour que ca soit plus petit niveau taille :
- *old_Software AG_directory/profiles/instance_name/logs*
- */IntegrationServer/instances/logs*
- */IntegrationServer/instances/instance_name/logs directories*
>- Ouvrir un powershell et lancer la commande dans le dossier à la racine de l'instances de l'InegrationServer :

   jar cfM ZIP_file_name.zip * 

>- Copier le zip sur la machine cible

- Migration base de données + run script
>- aller dans le dossier : New_SoftwareAG_directory/IntegrationServer/bin/migrate
>- lancer la commande

   migrate.{bat|sh}

>- entrer le chemin comportant le zip file
>- The utility asks whether to import migration settings. Enter N ??????????????
>- Migrer tous les packages
>- Trading network ?????????
>- *Any Java Service Wrapper #include directives are migrated to the end of the new
custom_wrapper.conf file; check them and adjust as necessary. The custom_wrapper.conf file is
located in the Software AG_directory/profiles/IS_instance_name/configuration directory*
>>- Update WSDL:
>regarder le fichier : new_SoftwareAG_directory/install/logs/migrationLog.txt
>Si cette erreur :

    A property watt.server.xml.ncname.encode.backward.compatibility exists in config/server.cnf with value as true. Make sure you make the required changes as specified in the upgrade documentation. Not doing so could have adverse effects as support for this property may be dropped in a future release. 

>>- *a. Open the new Integration Server Administrator or Microservices Runtime Administrator,
and connect to the new Integration Server or Microservices Runtime.
b. Go to the Settings > Extended page. If you have the extended setting
watt.server.xml.ncname.encode.backward.compatibility and it is set to true,reset it to false.
c. Regenerate the clients for all Provider Web services that have an operation with field*
>- If your solution includes publishable document types with an encoding type of protocol buffers,
you need to edit, save, and synchronize the publishable document types to Universal Messaging
while the queues of subscribing triggers are empty

***
***

## My webMethods Server
>- Installer nouvelle machine (template composite)
>- Preparer ancienne install
>- shutdown
>- Création du zip
>- aller dans *old_SoftwareAG_directory/MWS/bin/migrate* ou *old_Software AG_directory/MWS/bin*

ZIP-mws.{bat|sh}

>- Copier le zip dans un dossier du nouveau serveur
>- **Migrer database component**
>- Migrate Using Imported Settings
Imported settings can come from the following:
Settings you exported from a custom migration. These settings are stored in a file named
migrate.dat in the new_Software AG_directory/MWS/bin/migrate directory. Copy the migrate.dat
file to any directory on machines that host new My webMethods Server installations to which
you want to migrate data.
Settings in the default migrations provided by Software AG with My webMethods Server. For
each old release, the settings are stored in a file named migrateold_releasesbs.dat file in the
new_Software AG_directory/MWS/bin/migrate directory. The settings tell the migration utility
to migrate all instances within the old installation to the new installation, and to use the live
database.
>- Si erreur cf p.49
>- Initialisation de l'instance
> Aller dans *new_SoftwareAG_directory/MWS/bin*

mws.{bat|sh} -s instance_name init

> Vérification du hostName:
>>- If the old and new My webMethods Server installations are on different machines, verify the
host name for the new installation as follows:
a. Log on to one of the new My webMethods Server instances as Administrator and go to the
Administration > My webMethods> Cluster Settings > Advanced Web and Cluster
Configuration for MWS page.
b. If the host name is not correct in the Host and MWS Front End URL field, update the host
name.
c. Go to the Cluster Status and Control page and restart the instance.

>- Configure Products, Update Host Names, Adjust Assets for Release Changes, Re-enable Auto-Startup -> **cf p.51-52**

## Universal Messaging
>- Installer les derniers fix Lancer l'ancienne l'um ????????????????
>- couper l'um
>- Création du zip
>> *Software AG_directory/jvm/jvm/bin*
>> Lancer le scipt

jar cfM ZIP_file_name.zip install/products UniversalMessaging/server

>- Copier dans nouveau server (scp)
>- Aller sur la nouvelle machine et lancer le migrate.bat : *new_SoftwareAG_directory/UniversalMessaging/tools/migrate*

migrate.{bat|sh}

>- Imported setting ? Choisir N : The utility asks whether to import migration settings. Enter N.
>> Sinon si on doit les importer modifier le fichier migrate.dat *new_Software AG_directory/UniversalMessaging/tools/migrate*

## Api Gateaway

>- Installer les fix sur l'ancienne APIGateway
>- Eteindre les deux apigateway source et target
>- **Migrate database component** (skip)
>- Configurer le fichier elasticsearch.yml dans <TARGET>\InternalDataStore\config
>>reindex.remote.whitelist
>-

    reindex.remote.whitelist: IP_SERVEUR_SOURCE:PORT_SOURCE

>- cette propriété doit avoir la meme valeur que pg.gateway.elasticsearch.hosts présent dans <SOURCE>\IntegrationServer\instances\default\
packages\WmAPIGateway\config\resource\elasticsearch\config.properties
>- Exemple :

cluster.name: SAG_EventDataStore
node.name: SAG-1YVHZY21633236119876
path.logs: C:\SoftwareAG_1011\InternalDataStore/logs
network.host: 0.0.0.0
http.port: 9240
discovery.seed_hosts: ["localhost:9340"]
transport.tcp.port: 9340
path.repo: ['C:\SoftwareAG_1011\InternalDataStore/archives']
cluster.initial_master_nodes: ["node1"]
reindex.remote.whitelist: IP_SERVEUR_SOURCE:PORT_SOURCE

~~>Par conséquent replacer la valeur pg.gateway.elasticsearch.hosts du fichier config.properties présent sur la source par : http://IP_SERVEUR_SOURCE:PORT_SERVEUR_SOURCE~~

~~Exemple
**Cela signifie que si l'ip source est : 5.196.8.160:4180 il faudra modifier la valeur pg.gateway.elasticsearch.hosts=5.196.8.160:4180 présente dans <SOURCE>\IntegrationServer\instances\defaultpackages\WmAPIGateway\config\resource\elasticsearch\config.properties**~~
>- Si elasticsearch protégé:
Configure the basic authentication credentials to connect to the source Elasticsearch, if the
source Elasticsearch is protected.
To configure the basic authentication credentials, add the following properties to the
config.properties file located at <SOURCE>\IntegrationServer\instances\default\packages\
WmAPIGateway\config\resources\elasticsearch:
pg.gateway.elasticsearch.http.username=<username>
pg.gateway.elasticsearch.http.password=<password>

>- SI HTTPS:
>>- Ajout du certificat source (clé publique) dans <TARGET>\jvm\jvm\jre\lib\security
>- **Note:
If, external Elasticsearch is used for the target API Gateway, then the certificates must be imported to its corresponding JVM.**
>>- Exemple :

<TARGET>\jvm\jvm\bin\keytool -import -keystore
<TARGET>\jvm\jvm\jre\lib\security\cacerts -file <truststore.jks> -alias <alias>

>- Allumer ElasticSearch sur l'env cible et l'env source en vérifiant que les instances d'ag ne sont pas démarrées
_Exemple: <source>/InternalDataStore/bin/startup.sh + <cible>/InternalDataStore/bin/startup.sh_

>- **Si source et target sur meme machine faire attention au conflits de ports**

>- Si vous rétablissez les ports elasticsearch dans le fichier elasticsearch.yml après la migration, alors vous devez spécifier les mêmes ports dans le fichier config.properties situé dans <TARGET>/ IntegrationServer/instances/default/packages/WmAPIGateway/config/resources/

### Migration
>- Aller dans <TARGET>\IntegrationServer\instances\default\packages\WmAPIGateway\bin\migrate
- Deux cas (effectuer uniquement le premier point le second est applicable a partir de la 10.11):
>- **Volume de données bas** :

migrate.bat datastore -dstoreSrc <full path to source Elasticsearch
config.properties>

>Par exemple si on souhaite migrer le serveur 5.196.8.160:4180 qui contient une apigateway d'instance "ag". Il faudra copier le config.properties présent dans <Source>IntegrationServer/instance/ag/packages/WmAPIGateway/config/resources/elasticsearch/config.properties sur le nouveau serveur ou on le souhaite (exemple dans /home/centos/saveConfig/config.properties) et passer le chemin dans l'appel du migrate ce qui donne : ./migrate.sh datastore -dstoreSrc /home/centos/saveConfig/config.properties

**Modifier fichier config.properties**
> pg.gateway.elasticsearch.hosts=SOURCE_IP:SOURCE_PORT

**NOTE** Dans notre cas l'instance se nome "ag" il faudra donc modifier le fichier migration.properties (présent dans le répertoire actuel : migrate)
Remplacer la valeur : apigateway.migration.srcTenantName=default par le nom de l'instance ici "ag"

Une fois cice fait la migration des datas et des statistiques est effectuée cela peut prendre un certain temps.

**NOTE 2** Lors de la migration une backup est automatiquement réalisé et ce situe dans /InternalDataStore/archives/
(InternalDataStore/config/elasticsearch.yml --> path.repo)
Il est possible de restaurer la backup à l'aide de la commande dans <target>IntegrationServer/instances/ag/packages/WmAPIGateway/cli/bin :

./apigatewayUtil.sh restore backup -tenant ag -repoName migration_ag -name 'backup_name'

**ps**

./apigatewayUtil.sh list backup -repoName #repoName est le nom du dossier dans archives contenant la backup

Se référer a **Fin**

>- **Volume de données haut** (**dispo depuis 10.11**): 2 phases : data puis analytics

>Phase 1

migrate.bat datastore -dstoreSrc\chebackup01\installations\source\IntegrationServer\instances\default\ packages\WmAPIGateway\config\resources\elasticsearch\config.properties

>Phase 2 Migrer données statistiques (analytics data) en utilisant backup and restore

<SOURCE>\IntegrationServer\instances\default\packages\WmAPIGateway\
cli\bin\apigatewayUtil
create backup -include analytics -name <backup_file_name>

> Copy the backup file to the target API Gateway instance path.repo folder configured under <TARGET>\IntegrationServer\InternalDataStore\config\elasticsearch.yml.

> Restore the backup data in the target API Gateway instance using the following command:

cli\bin\apigatewayUtil
restore backup -include analytics -name <backup_file_name>.

>- **Migrate the platform configurations ????? (ca migre quelles conf ??? )**:
> Aller dans : <TARGET>\IntegrationServer\instances\default\
packages\WmAPIGateway\bin\migrate

migrate.bat apigateway -srcDir <SOURCE> -instanceName <source instance name> -newInstanceName <target instance name>

**Fin**
>- Couper elasticsearch
>- Allumer apigateway
>- Check les logs dans : <TARGET>/install/logs/migrationLog.txt.
>- Check rapport de mogration : <TARGET>\install\logs\APIGW_
Migration_Reports_<date_time>

## backup / restore apigateway elasticsearch

Lors de la première analyse j'ai voulu effectuer un backup / restore des datas et analytics afin d'effectuer ma migration. Cette façon de faire a fonctionnée mais n'est pas correcte car la phase de migration n'est pas réellement effectuée.

>- Procédure pour réaliser un backup :
### 1) Se positionner sur le serveur source

cd <source>IntegrationServer/instance/ag/packages/WmAPIGateway/cli/bin/

La commande permettant de réaliser un backup est la suivante :

./apigatewayUtils.sh create backup -name "nomBackup"

plusieurs options sont possibles :
-tenant : nom de l'instance de l'ag (dans notre cas elle se nomme ag)
-name : spécifier le nom du spanshot
Dans notre cas la commande est :

/apigatewayUtils.sh create backup -tenant ag -name "nomBackup"

Pour savoir ou le backup se créé aller dans : <source>/InternalDataStore/config/elasticsearch.yml et regarder la valeur de path.repo (par défaut cela se situe dans <source>/InternalDataStore/archives/ )
dans notre cas : <source>/InternalDataStore/archives/ag
Le backup est réalisé dans un dossier portant le nom du tenant (donc le nom de l'instance)
Copier le backup dans le serveur cible dans <cible>/InternalDataStore/archives/ag

>- Procédure pour restorer un backup :
### 2) Se positionner sur le serveur cible

cd <source>IntegrationServer/instance/ag/packages/WmAPIGateway/cli/bin/

lancer la commande :

./apigatewayUtils.sh restore backup -name "nomBackup"

plusieurs options sont possibles :
-tenant : nom de l'instance de l'ag (dans notre cas elle se nomme ag)
-name : spécifier le nom du spanshot
-repoName(NON OBLIGATOIRE): le nom du repository dans lequel est le backup ( normalement égal au nom de l'instance)
- include [analytics, assets...]
Dans notre cas la commande est :

/apigatewayUtils.sh create backup -tenant ag -name "nomBackup"

**NOTE la commande de restore ne marche pas direct il faut dans un premier temps lancer la commande de restore uniquemet des analytics pour ensuite effectuer le restore global ce qui donne:**

/apigatewayUtils.sh create backup -include analytics -tenant ag -name "nomBackup"
/apigatewayUtils.sh create backup -tenant ag -name "nomBackup"

## Database component

>- Aller dans : new_Software AG_directory/common/
/bin directory
>- Lancer :

dbConfigurator.{bat|sh} --action migrate --dbms
{db2luw|mysql|oracle|sqlserver|pgsql|tibero}
{--component db_component[,db_component...] | --product product[,product...]}
--version latest --url db_server_URL --user existing_db_user --password password

>- If you are using an Oracle or DB2 RDBMS, and you are not using the default tablespace, also
specify the -tsdata data_tspace_name and -tsindex index_tspace_name parameters. (Voir page 154-155 pour plus d'infos)