stagingprop, utilitaire

L'utilitaire stagingprop extrait tous les enregistrements STAGLOG non traités et les traite. Un enregistrement STAGLOG non traité est tout enregistrement où la valeur de la colonne STGPROCESSED est définie sur 0. Un utilitaire stagingprop qui aboutit met à jour ces enregistrements STAGLOG dans la colonne STGPROCESSED de non traité (0) à traité (1). Utilitaire stagingprop consolidation et propagation. Au cours de la consolidation, stagingprop examine STAGLOG et détermine les enregistrements STAGLOG qui peuvent être marqués comme étant traités sans propagation. Les enregistrements STAGLOG traités sont ensuite propagés dans la base de données de production.

Vous pouvez exécuter une consolidation stagingprop sans propagation en omettant les paramètres suivants : destdb, destdb_user et dest_passwd. Si certains des paramètres sont fournis, ou si l'utilitaire stagingprop ne peut pas établir une connexion à la base de données de production avec les paramètres, l'utilitaire ne s'exécute pas correctement.

delete from STAGLOG where stgrfnbr=-1; 

Pour exécuter l'utilitaire stagingprop, tapez cette commande dans une ligne de commande sur un système pouvant se connecter à la fois à l'environnement de transfert et à la base de données de l'environnement de production.

Valeurs des paramètres

dbtype

• Facultatif : Spécifiez DB2. DB2 est le type de base de données par défaut et vous pouvez omettre le paramètre -dbtype de la commande.
• Obligatoire : Spécifiez Oracle.

portée

Facultatif : niveau de portée de la table pour la publication sur le serveur de production. Utilisez ce paramètre pour filtrer la publication par table.

Indiquez l'un des paramètres suivants :

_all_

Spécifiez _all_ pour publier tous les enregistrements.

Copie à la fois les enregistrements associés au site et ceux associés à tous les commerçants. Les enregistrements sont copiés dans l'ordre suivant :

1. Les enregistrements de site sont copiés à partir de STGSITETAB
2. Les enregistrements de site sont copiés à partir de STGMRSTTAB
3. Les enregistrements de commerçant sont copiés à partir de STGMERTAB
4. Les enregistrements de commerçant sont copiés à partir de STGMRSTTAB

_site_

Spécifiez _site_ pour publier uniquement les enregistrements associés au site. Les enregistrements associés au site sont des données communes à tous les commerçants, par exemple, la langue et le code de pays ou de région utilisés par le système. Ces données proviennent de la table STGSITETAB.

_merchant_

Spécifiez _ merchant_ pour publier uniquement les enregistrements associés au commerçant. Par exemple, les informations de magasin sont personnalisées pour chaque commerçant et les lignes des tables de magasin sont spécifiques de chaque commerçant.

Remarque : Vous devez copier toutes les données pour tous les commerçants et non pas uniquement les données pour un commerçant spécifique. Ces données proviennent de la table STGMERTAB.

s

Spécifiez une liste de portées personnalisées, comme indiqué dans le fichier spécifié par le paramètre configfile s. Si vous indiquez une portée personnalisée, vous devez spécifier le paramètre configfile s. Vous pouvez spécifier plusieurs listes de portée en séparant les noms des listes par une barre oblique ("/").

L'utilitaire stagingprop suit l'ordre des tables de la base de données figurant dans la ou les listes fournies. Lorsque vous créez des listes de tables de base de données, vérifiez que les tables référencées figurent avant les tables de référence dans la liste.

configfile s

Chemin complet du fichier contenant les informations de portée pour la portée personnalisée. Pour les instructions de création de ce fichier, reportez-vous à la rubrique

Création d'une liste de filtrage de base de données.

Remarque : Si vous ne définissez pas la portée par _all_ :

• Propagez les données de site avant les données de commerçant, car les données de site sont utilisées par tous les commerçants. Sinon, la propagation échoue en raison d'une non-concordance entre les clés externes et primaires.

sourcedb

Obligatoire : nom de la base de données dans l'environnement de transfert.

s doit être une URL JDBC valide et complète ou suivre la convention de nom de base de données Type 4 :

• db_server:db_port/db_name.

sourcedb_user

Obligatoire : ID de connexion du propriétaire de schéma de base de données qui a créé le schéma de la base de données source ou de la base de données de production.

sourcedb_passwd

Obligatoire : mot de passe associé à l'ID de connexion indiqué par le paramètre sourcedb_user.

sourcedb_schema

Facultatif : spécifie le schéma sur la base de données source où toutes les opérations d'entreprise sont conduites. Spécifiquement, ce schéma doit avoir tous les objets de base de données requis par une instance HCL Commerce active. Lorsque ce paramètre n'est pas spécifié, la valeur par défaut est le schéma actif dans la base de données source lorsqu'une connexion est établie.

destdb

Obligatoire : nom de la base de données dans l'environnement de production.

s doit être une URL JDBC valide et complète ou suivre la convention de nom de base de données Type 4 :

• db_server:db_port/db_name.

Remarque : Si vous ne voulez pas propager les données consolidées à l'environnement de production, n'utilisez pas ce paramètre.

destdb_user

Obligatoire : ID de connexion du propriétaire de schéma de base de données qui a créé le schéma de la base de données source ou de la base de données de production. Ce paramètre est mandatory en cas d'utilisation d'une base de données éloignée.

Remarque : Si vous ne voulez pas propager les données consolidées à l'environnement de production, n'utilisez pas ce paramètre.

destdb_passwd

Obligatoire : mot de passe associé à l'ID de connexion indiqué par le paramètre destdb_user. Si vous n'indiquez rien, le système vous invite à saisir le mot de passe. Ce paramètre est obligatoire en cas d'utilisation d'une base de données distante.

Remarque : Si vous ne voulez pas propager les données consolidées à l'environnement de production, n'utilisez pas ce paramètre.

destdb_schema

Facultatif : spécifie le schéma sur la base de données cible où toutes les opérations d'entreprise sont conduites. Spécifiquement, ce schéma doit avoir tous les objets de base de données requis par une instance HCL Commerce active. Lorsque ce paramètre n'est pas spécifié, la valeur par défaut est le schéma actif dans la base de données de destination lorsqu'une connexion est établie.

destdb_locktimeout

• Facultatif : spécifie le nombre de secondes pendant lequel la connexion de l'utilitaire stagingprop à la base de données de production doit attendre pour l'obtention d'un verrouillage sur la base de données qu'il vient de mettre à jour. Si l'utilitaire stagingprop ne peut obtenir ce verrouillage dans le temps imparti, la transaction de la base de données est annulée.

  Spécifiez une valeur (0) pour que l'utilitaire stagingprop attende jusqu'à ce qu'il obtienne un verrouillage sur l'enregistrement de base de données qu'il veut mettre à jour.

  Si vous ne spécifiez pas ce paramètre, l'utilitaire stagingprop observe un délai d'attente correspondant à la valeur définie par défaut dans la configuration de base de données. Prenez contact avec votre administrateur de base de données pour connaître la valeur du délai d'attente de verrouillage par défaut.

transaction

Facultatif : indique le nombre de modifications effectuées avant qu'elles ne soient validées dans la base de données de production. Si vous ne spécifiez pas ce paramètre, les journaux des modifications sont validés sur l'action one.

un

L'utilitaire stagingprop exécute une transaction unique et n'est validé qu'une fois que la publication aboutit. Si la publication échoue, la transaction est annulée et l'état de la base de données de production antérieur à l'exécution de l'utilitaire stagingprop est restauré.

Liste

Les modifications apportées à la base de données de production sont validées une fois que tous les journaux de modifications concernant la liste de tables de base de données spécifiée au paramètre scope sont traités. Vous devez définir les paramètres -scope et configfile s pour indiquer ce niveau de transaction.

table

Les modifications apportées à la base de données de production sont validées, une fois traitées toutes les opérations concernant une table de la base de données de production.

n

Les modifications apportées à la base de données de production sont validées, après le traitement de chaque transaction n. Si vous spécifiez le paramètre batchsize associé à cette valeur du paramètre transaction, les modifications apportées à la base de données de production sont validées en fonction d'un multiple de la valeur du paramètre batchsize, égal ou supérieur à la valeur du paramètre transaction.

Par exemple, si vous spécifiez transaction 35 et batchsize 20, les modifications apportées à la base de données de production sont validées toutes les 40 modifications. 40 est le nombre de modifications le plus proche, qui soit un multiple du paramètre batchsize égal ou supérieur au paramètre transaction. Si vous indiquez transaction 20 et batchsize 35, les modifications apportées à la base de données de production sont validées toutes les 35 opérations.

filter

Facultatif : spécifiez la valeur de la marque de filtrage permettant de sélectionner les enregistrements à publier. Utilisez ce paramètre pour sauvegarder la publication par enregistrement.

Par défaut, l'option filter vérifie la valeur de la marque de filtrage dans la colonne STGFILTER de la table STAGLOG. Si des valeurs de marque de filtrage figurent dans une autre colonne de la table STAGLOG, utilisez l'option filtercolumn pour spécifier la colonne dans laquelle vous avez défini la valeur de marque de filtrage.

Les valeurs de marque de filtrage doivent être des entiers positifs. Les valeurs zéro ou négatives sont réservées à l'usage interne d'HCL.

HCL Commerce ne fournit pas d'outils permettant de définir ou de valider les valeurs de marque de filtrage. Vous devez vérifier que la valeur de marque de filtrage utilisée par un ensemble de modifications est différente de celle utilisée par un autre ensemble de modifications.

filtercolumn

Facultatif : indique la colonne de la table STAGLOG qui contient les valeurs de marque de filtrage. La colonne qui est spécifiée doit être de type INTEGER.

batchsize

Facultatif : Active et désactive les mises à jour SQL par lots et spécifie le nombre d'enregistrements de journaux des modifications consolidés à inclure dans une instruction SQL par lots. Les enregistrements des journaux des modifications sont consolidés selon le réglage du paramètre consolidationSize.

Si vous ne spécifiez pas ce paramètre, le paramètre batchsize défini par la valeur 100.

La définition du paramètre -batchsize par une valeur 0 (zéro) désactive la mise à jour SQL par lots.

Désactivez le traitement SQL par lots si vous publiez l'une des modifications suivantes à partir des données prêtes pour la production vers l'environnement de production :

• Utilisation d'un espace de travail pour supprimer un objet HCL Commerce affectant la table MEMBER. Ceci comprend des objets comme utilisateurs, organisations, segments de clientèle, groupes de membres, groupes de territoires de clientèle ou groupes de prix client.

Quand une mise à jour SQL par lots est activée, les enregistrements des journaux des modifications sont triés par type de modification (insertion, mise à jour ou suppression). Chaque lot contient des modifications d'un seul type. Par exemple, s'il y a 102 modifications de type insertion et que le paramètre batchsize est défini par la valeur 100, deux lots SQL seront créés : un lot avec 100 opérations d'insertion et l'autre avec 2 opérations d'insertion.

L'utilisation des mises à jour SQL par lots permet d'accélérer la mise à jour de la base de données de production par l'utilitaire stagingprop.

Remarque :

• La création de lots JDBC peut provoquer un traitement d'erreurs incohérent. La définition de batchsize sur 0 désactive la création de lots JDBC et facilite l'identification des enregistrements à l'origine des erreurs.
• Pour générer un fichier journal complet, définissez un niveau de suivi plus élevé pour suivi. Pour plus d'informations, voir le paramètre suivi.

retry

Facultatif : indique le nombre maximal de tentatives de relance d'une transaction par l'utilitaire stagingprop, lorsqu'une transaction est annulée.

waittime

Facultatif : indique le nombre de secondes pendant lequel l'utilitaire stagingprop attend entre deux nouvelles tentatives de relance.

Si vous ne spécifiez pas le paramètre retry, l'utilitaire stagingprop ne relance pas une transaction lorsqu'elle est annulée. L'utilitaire stagingprop se ferme sur une erreur.

consolidationSize

Facultatif : exécute la phase de consolidation de stagingprop table par table, et non en traitant toutes les tables à la fois. Lorsqu'il est utilisé, ce paramètre limite le nombre d'enregistrements extraits de la base de données à un moment donné pendant la phase de consolidation en fonction du nombre défini.

Lorsque ce paramètre n'est pas spécifié, le comportement par défaut de stagingprop consiste à exécuter la phase de consolidation en une seule fois pour tous les enregistrements non traités dans la table STAGLOG. Si la taille spécifiée est supérieure au nombre total d'enregistrements non traités dans la table STAGLOG, le comportement par défaut de l'utilitaire stagingprop est rétabli.

L'utilisation de consolidationSize présente le principal avantage d'éviter la fin anormale de l'utilitaire stagingprop en raison d'instances de java.lang.OutOfMemoryError ou les problèmes liés à l'épuisement de l'espace de journal transactionnel de base de données. L'exécution de la phase de consolidation table par table réduit considérablement l'encombrement du consolidation de la machine virtuelle Java pendant la consolidation.

Considérez le scénario suivant, dans lequel la valeur indiquée pour consolidationSize est x et le nombre total d'enregistrements non traités dans la table STAGLOG est y :

1. Si x >= y, la phase de consolidation de stagingprop conserve le comportement par défaut.
2. Sinon, supposez une table de transfert, A, dont le nombre total d'enregistrements non traités dans la table STAGLOG est z :
   1. Si z <= x, le jeu complet d'enregistrements non traités de A dans la table STAGLOG est récupéré une seule fois.
   2. Si z > x, les enregistrements non traités de A dans la table STAGLOG sont récupérés dans (1 + plancher(z/x)) nombre d'extractions.

Une règle empirique que nous vous recommandons d'utiliser lorsque vous déterminez comment spécifier consolidationSize consiste à limiter à une le nombre d'extractions à effectuer pour chaque table à consolider. L'instruction SQL suivante permet d'extraire le nombre d'enregistrements non traités dans la table STAGLOG pour chaque table de transfert :

select q.* from (select count(*) numrecs, stgtable from staglog where stgprocessed = 0 group by stgtable) q order by q.numrecs desc, q.stgtable

La sortie est triée dans l'ordre décroissant du nombre d'enregistrements non traités pour chaque table de transfert.

log

Facultatif : chemin d'accès et nom du fichier dans lequel l'utilitaire stagingprop enregistre ses activités et ses erreurs. Il est possible d'ajouter la valeur d'horodatage au nom de fichier, par exemple, myLog_ yyyy.mm.dd_hh.mm.ss.zzz.log.

Si ce paramètre n'est pas indiqué, le fichier journal stagingprop_yyyy.mm.dd_hh.mm.ss.zzz.log est créé dans le répertoire suivant utilities_root/logs.

actionOnError

Facultatif : définit le niveau de tolérance d'erreur.

Utilisez actionOnError pour définir le comportement de l'utilitaire stagingprop lorsqu'il détecte des erreurs. Dans certaines situations, stagingprop doit tolérer des erreurs pour propager rapidement des données. Dans certains autres cas, stagingprop doit se fermer lorsqu'une erreur est détectée.

-actionOnError prend en charge trois valeurs :

0

En cas d'erreur, lancer une exception et quitter.

1

En cas d'erreur, passer au suivant.

2

Tolérer les erreurs de consolidation et lorsqu'une erreur se produit, passer au suivant.

Si une collision de clé primaire ou une violation d'index unique a lieu lorsque actionOnError est défini sur 1 ou 2, stagingprop enregistre l'erreur dans le journal et continue. De même, si une erreur est détectée, la propagation stagingprop marque l'enregistrement STAGLOG, colonne STGPROCESSED, correspondant à l'aide de l'une des valeurs suivantes :

-1

Opération de suppression sans résultat ni erreur

-2

Opération de mise à jour sans résultat ni erreur

-3

Opération d'insertion sans résultat ni erreur

-4

Erreur détectée lors de la consolidation. La valeur -4 est consignée lorsque des erreurs de consolidation sont tolérées (la valeur de actionOnError est 2.)

-5

La clé primaire pour la table qui est spécifiée dans la colonne STGTABLE est introuvable dans la table physique sur la base de données de transfert. La valeur -5 est consignée, que le paramètre actionOnError soit spécifié ou non.

Si l'exception se produit au sein d'un lot, seul l'enregistrement défaillant est marqué comme erreur, et stagingprop poursuit avec le reste du lot.

Si une exception se produit dans un lot, tous les enregistrements jusqu'au premier enregistrement ayant échoué sont validés sur la base de données de production. Cependant, tous les enregistrements sont marqués comme -3 dans la table STAGLOG sur la base de données de transfert.

trace

Facultatif : Définit le niveau de traçage dans le journal. suivi a quatre valeurs possibles :

0

Récapitulatif de haut niveau uniquement.

1

Informations au niveau table et état récapitulatif global.

2

Rapport d'état récapitulatif et informations au niveau ligne.

3

Instructions SQL et diagnostic.

Remarque : Les valeurs de suivi sont incrémentielles. Chaque valeur comprend le niveau de détail de la valeur précédente.

lockStaglog

Facultatif : indique si stagingprop acquiert un verrou EXCLUSIVE sur la table STAGLOG. lockStaglog comporte deux valeurs possibles :

0

Aucun verrou n'est acquis.

1

Un verrou de type EXCLUSIVE est acquis.

cutoffTime

Facultatif : définit la valeur de la durée à partir de laquelle stagingprop cesse son examen. L'utilitaire stagingprop n'examine aucun des enregistrements de table STAGLOG correspondant aux données qui sont insérées après la valeur d'horodatage spécifiée.

Spécifiez la valeur d'horodatage à l'aide du modèle yyyy-MM-dd.HH:mm:ss. Placez la valeur cutoffTime entre guillemets pour éviter toute erreur. Pour plus d'informations, voir Class SimpleDateFormat.

Par exemple :

<stagingprop-executable> [<other-arguments>] -cutoffTime "2011-10-05.12:25:00" [<other-arguments>]

paramfile

Facultatif. Indique le chemin d'accès au fichier de paramètres qui comprend les arguments et les valeurs de ligne de commande. Chaque argument et chaque valeur doit être au format argument=value avec un seul argument et une seule valeur sur chaque ligne de ce fichier. Tous les mots de passe dans ce fichier de paramètres doivent être chiffrés.

customfilter%

Facultatif. Indique une condition de filtre personnalisé que l'utilitaire stagingprop doit utiliser pour filtrer les données que l'utilitaire stagingprop publie. Lorsque l'utilitaire s'exécute, seuls les enregistrements pour les objets qui correspondent à la condition de filtre spécifiée sont traités et propagés à la production. La valeur que vous définissez pour le paramètre customfilter% est transmise à l'instruction SQL qui est définie dans un fichier de configuration du filtre de transfert. Ce fichier XML de configuration doit définir le SQL pour savoir comment l'utilitaire stagingprop traite les objets qui correspondent à la condition de filtre personnalisé. Vous pouvez inclure plusieurs filtres personnalisés dans une opération de transfert unique.

Pour utiliser le paramètre customfilter% dans la ligne de commande, SQL doit inclure un paramètre {customfilterparametername}. La valeur parametername dans l'instruction SQL doit correspondre à la valeur '%' dans la ligne de commande.

Par exemple, vous pouvez définir le SQL pour une condition de filtre personnalisé qui propage uniquement les données qui appartiennent à un magasin spécifique. Dans ce SQL, vous pouvez inclure le paramètre {customfilterstoreid} pour représenter la valeur d'ID de magasin. Ensuite, lorsque vous exécutez l'utilitaire stagingprop, vous spécifiez l'ID du magasin comme valeur pour le paramètre personnalisé customfilterstoreid. Cette valeur remplace alors le paramètre {customfilterstoreid} dans l'instruction SQL pour traiter les enregistrements de ce magasin.

filterconfigfile

Facultatif. Indique le fichier XML de configuration du filtre de transfert qui définit le SQL pour savoir comment l'utilitaire stagingprop doit filtrer et traiter des enregistrements pour la publication d'objets spécifiques. Si un paramètre et une valeur customfilter% sont définis dans la ligne de commande, l'utilitaire remplace la valeur dans la condition de filtre SQL. L'utilitaire propage ensuite uniquement les données qui correspondent à la condition de filtre. Lorsque vous spécifiez la valeur pour le fichier de configuration du filtre de transfert, incluez le chemin relatif au fichier de configuration à partir du répertoire bin.

forceFileProp

Facultatif : Indiquez si l'utilitaire fileprop doit être exécuté.

Pour exécuter l'utilitaire fileprop, définissez forceFileProp sur Yes. Par défaut, forceFileProp a pour valeur no.

assetTargetDirectory

Répertoire dans lequel les fichiers gérés à partir de la création doivent être copiés pour le montage du fichier de production. (c'est-à-dire /SETUP/assets/live)