2009-01-02 8 views
1

Il y a des paramètres que je ne voudrais pas transférer de l'environnement de production à qa. Le personnel aime le chemin du réseau et l'URL. Le problème est que dans sap abap tout est dans la base de données et lorsque la base de données est copiée dans le système qa, vous devez modifier manuellement ces paramètres. Et c'est sujet aux erreurs.Comment stocker les informations de configuration dans l'application sap abap?

Existe-t-il un moyen de stocker les informations de configuration d'une manière qui ne sera pas transférée avec la base de données?

Merci.

Répondre

2

En bref: pas - au moins ce serait très inhabituel dans un environnement SAP.

Si votre système de contrôle qualité est configuré en tant que copie système de votre environnement de production (qui est le chemin habituel), il existe plusieurs étapes à suivre pour que le système fonctionne correctement. Cela inclut une certaine configuration, qui peut être aussi simple que les chemins de fichiers comme ceux que vous mentionnez, mais aussi les adresses et les noms des "systèmes partenaires". Par exemple, un de mes clients est une banque, alors quand il copie son système de production, il s'assure à coup sûr qu'aucune activité du côté de l'assurance-qualité ne tombe accidentellement du côté de la production. D'autres modifications sont également apportées, par exemple pour masquer les noms et les adresses des personnes afin qu'aucun courrier ne soit envoyé accidentellement, etc.

Il existe plusieurs façons de rendre ces modifications aussi simples que possible (recherchez des documents SAP ou des livres sur SAP Transport et Change management, j'en avais un par Sue McFarland Metzger ou alors c'était plutôt bien). D'après ce que j'ai vu, il y a généralement un ensemble de transports qui changent la configuration et la personnalisation etc. sur le système QA aux valeurs appropriées .

Espérons que ça aide.

+1

Merci. Ce que vous décrivez est, plus ou moins, ce que nous faisons. C'est difficile pour moi de croire qu'il n'y a pas de meilleur moyen. Je crois toujours que d'une certaine manière, cela devrait être une affaire en un clic. Mais votre réponse est ce que j'entends tout le temps. Et les scripts sont trop fragiles. donc ... –

+0

Vos commentaires sont vrais .. mais faire une copie devrait être un événement assez rare. Si pas autre chose ne va pas ... – Thorsten

+0

Peut-être que quelque chose d'autre est faux. Mais nous le faisons assez souvent sur l'un de nos environnements de qa, d'intégration ou de formation. –

0

votre question n'est pas claire, parlez-vous de config standard ou personnalisé? Salutations, en supposant que vous stockez ces chemins dans une table Z, certaines boutiques placent sy-sysid (ID système) comme l'une des colonnes. Maintenir tous les systèmes dans votre dev et le transport à la production. Cela devient douloureux après un certain temps, donc je ne le suggérerais que pour des informations qui ne changent pas beaucoup (les chemins de fichiers peuvent être bons).

T.

+0

Disons que je veux écrire un fichier sur un partage. En production et en qa, la part est dans un chemin différent. Où dois-je stocker le chemin? –

0

Vous ne pouvez pas empêcher la copie de la configuration stockée dans la base de données dans l'instance clonée. Toutefois, vous pouvez concevoir le stockage de la configuration d'une manière qui empêchera l'utilisation des entrées copiées. Vous devriez vérifier auprès de vos administrateurs de base s'ils peuvent garantir que le système cloné obtiendra un nouvel ID système (SID). Si tel est le cas, vous pouvez simplement utiliser le SID comme champ clé dans votre table de configuration. Après la copie du système, le SID sera modifié et le système cloné n'accédera plus aux entrées d'origine.