Considerações Adicionais

As seções a seguir descrevem algumas considerações adicionais para o CMA.

Considerações sobre Transferência de Arquivo

Ao mover o arquivo de exportação entre sistemas, use a opção de transferência binária da ferramenta que estiver usando para mover o arquivo, assim, os caracteres de fim de linha não serão convertidos do estilo Linux para o estilo Windows, ou vice-versa.

Recomenda-se evitar usar "txt" como extensão do arquivo de exportação (definido na configuração principal). Essa extensão de arquivo por padrão implica em um arquivo não binário e as ferramentas que transferem o arquivo podem tratá-lo como um arquivo não binário, a menos que explicitamente indicado. A recomendação é definir "cma" como extensão. Não é uma extensão de arquivo reconhecida e a maioria das ferramentas de transferência de arquivos manterá o arquivo como está.

Observe que, se o arquivo for convertido, há dois resultados possíveis: um erro de conversão numérica ou um erro de subexecução em buffer podem ser emitidos ao tentar importar o arquivo.

Considerações sobre Ambiente com Vários Idiomas

Se a implementação usa outro idioma além de inglês, isso significa que objetos de administração migrados podem ter linhas com diversos idiomas (já que inglês está sempre ativado). Há alguns pontos importantes acerca de vários idiomas e CMA:

  • Conforme descrito em Idioma do Usuário, existem etapas a serem seguidas quando houver suporte a mais de um idioma. As etapas descritas naquele tópico destacam que, para dados de sistema, a tradução das strings pode ser fornecida por um pacote de idiomas fornecido pelo produto, ou pode ser de responsabilidade de sua implementação. Em qualquer caso, esse esforço é importante e terá seu próprio plano definido. A expectativa é que a tradução de dados do sistema seja aplicada para cada região em seu local de implementação. O CMA não deve ser usado para criar um novo idioma em uma região de destino.

  • Para dados administrativos/de controle que sua implementação desenvolver como parte de seu projeto, espera-se que as descrições de seu idioma suportado sejam inseridas na região considerada como região de origem usada para promover alterações para regiões na "cadeia". Por exemplo, dados de controle são inseridos em uma região de desenvolvimento e promovidos para um teste com o idioma suportado ativado nas duas regiões.

  • E se você exportar dados de uma região com mais idiomas ativados do que seu destino? Esse cenário talvez seja um caso em que a região de origem seja um tipo de teste ou região cercada na qual o idioma adicional esteja ativado para outros fins. Nesse caso, se o código do idioma não existir realmente na região de destino, a importação produzirá um erro indicando que o código não é válido. Se o código do idioma existir, mas não estiver ativado, isso fará com as linhas adicionais de idioma sejam inseridas na região de destino, mas não causará nenhum problema. Eles são simplesmente ignorados.

  • E se você exportar dados de uma região com menos idiomas ativados do que seu destino? Nessa situação, o processo de importação criará somente linhas de idioma para os idiomas copiados da origem. Ele não criará automaticamente linhas de idiomas no destino como parte da importação. Para essa situação, a recomendação é executar o programa em batch Novo Idioma (F1–LANG), que cria as entradas de idioma ausentes.