X++

Práticas e padrões: Pack e Unpack

Eduardo Miranda — Sat, 09 Feb 2008 17:00:21 GMT

A serialização de objetos possibilita a persistência e/ou a transmissão de um objeto entre módulos fisicamente separados de uma aplicação. É um processo parecido com transformar o leite em pó e depois conseguir recriar o leite adicionando água.

Diversas linguagens oferecem funcionalidades de serialização, em X++ ela é feita através do padrão pack-unpack. Enquanto em .Net, por exemplo, o objeto pode ser serializado em xml ou outros formatos, no X++ o formato utilizado é o container. Vamos utilizar a classe Person para o nosso exemplo:

public class Person
{
    str     name;
    date    birthdate;
}

Mas em que consiste “empacotar” um objeto? Basicamente é guardar todas as variáveis deste objeto em um container. O processo inverso, “desempacotar” o objeto, é receber um container contendo os valores das variáveis e carregar as variáveis com estes valores.

Uma versão simplista, mas funcional, do pack-unpack seria assim:

public container pack()
{
    return [name, birthdate];
}

public void unpack(container _packed)
{;
    name        = conpeek(_packed, 1);
    birthdate   = conpeek(_packed, 2);
}

Veja a utilização do padrão. Primeiro crio um objeto pessoaA e coloco um nome e data de nascimento neste objeto. Utilizando o pack, guardo este objeto serializado em um container e, em seguida, destruo o objeto. Depois crio um novo Person, pessoaB, e, utilizando o unpack, restabeleço os valores do pessoaA neste novo objeto.

    Person pessoaA;
    Person pessoaB;
    container packed;

    pessoaA = new Person();
    pessoaA.parmName("Joao");
    pessoaA.parmBirthdate(10\10\2000);

    packed = pessoaA.pack();

    pessoaA = null;
    
    pessoaB = new Person();
    
    pessoaB.unpack(packed);
    
    print pessoaB.parmName();
    print pessoaB.parmBirthdate();

    pause;

Esta versão funciona, mas poderia ficar um pouco melhor. Preciso repetir cada variável nos dois métodos, pack e unpack, além disso preciso acertar a ordem do container, senão posso colocar o valor de uma variável em outra durante o unpack. Utilizando uma macro, que declaro na classe, consigo resolver estes problemas. Esta nova implementação fica assim:

public class Person
{
    str     name;
    date    birthdate;

    #LOCALMACRO.CurrentList
        name,
        birthdate
    #ENDMACRO
}

public container pack()
{
    return [#CurrentList];
}

public void unpack(container _packed)
{;
    [#CurrentList] = _packed;
}

Em CurrentList declaro as variáveis que desejo empacotar para esta classe. Depois o pack-unpack utilizam a lista, eliminando a duplicação de código.

Versionamento

Muitas vezes as classes evoluem, ganhando novas variáveis, dadas as necessidades do negócio. Neste caso teremos um problema, imagine que um container contendo um objeto serializado é persistido e depois de algum tempo a aplicação tenta “desempacotá-lo” na classe que agora contém novas variáveis. Não seria possivel, na nossa implementação.

Portanto precisamos de uma pequena mudança. Digamos que a classe Person agora também contém o sexo da pessoa como variável. Então tenho uma variável e um método parm para sexo:

public class Person
{
    str     name;
    date    birthdate;
    Gender  gender;

    #LOCALMACRO.CurrentList
        name,
        birthdate
    #ENDMACRO
}
public Gender parmGender(Gender _gender = gender)
{;
    gender = _gender;
    return gender;
}

Agora tenho que mudar a implementação do pack-unpack para que ele saiba diferenciar pacotes contendo um objeto da versão antiga, sem sexo, da nova, com sexo. Adiciono a variável da CurrentList, esta foi a parte fácil. Crio uma constante com a versão corrente, 2.

public class Person
{
    str     name;
    date    birthdate;
    Gender  gender;

    #DEFINE.CurrentVersion(2)
    #LOCALMACRO.CurrentList
        name,
        birthdate,
        gender
    #ENDMACRO
}

No pack a versão passa a ser a primeira variável empacotada

public container pack()
{
    return [#CurrentVersion, #CurrentList];
}

No unpack, verifico qual a versão do pacote recebido, e implemento um swicth para cada versão que a classe já teve. O método RunBase::getVersion() é um helper que lê o container descobre sua versão.

public void unpack(container _packed)
{
    int version;
    ;
    
    version = RunBase::getVersion(_packed);

    switch (version)
    {
        case #CurrentVersion:
            [version, #CurrentList] = _packed;
            break;

        default:
            [name, birthdate] = _packed;
    }
}

Veja a utilização, consigo desempacotar tanto um container contendo somente nome e data de nascimento, quanto a versão mais nova. Lógico que a variável gender assume o valor defaul, Unknown, quando o container não a possui.

    Person pessoaA;
    Person pessoaB;
    container packed;
    container oldPacked = ["Joao", 10\10\2000];

    pessoaA = new Person();
    pessoaA.parmName("Joao");
    pessoaA.parmBirthdate(10\10\2000);
    pessoaA.parmGender(Gender::Male);

    packed = pessoaA.pack();

    pessoaA = null;

    pessoaB = new Person();

    pessoaB.unpack(oldPacked);

    print pessoaB.parmName();
    print pessoaB.parmBirthdate();
    print pessoaB.parmGender();

    pessoaB.unpack(packed);

    print pessoaB.parmName();
    print pessoaB.parmBirthdate();
    print pessoaB.parmGender();

    pause;

Herança

Uma nova classe, Employee, é criada herdando da classe Person, empregado é uma pessoa, que também possui data de contratação.

class Employee extends Person
{
    date hiringDate;
}
public date parmHiringDate(date _hiringDate = hiringDate)
{;
    hiringDate = _hiringDate;
    return hiringDate;
}

Como é Employee filha de Person, posso utilizar os métodos pack-unpack, no entanto, como era de se esperar, a variável hiringDate não será empacotada. Se eu simplesmente sobrescrever o pack-unpack e implementar minha própria versão, estarei duplicando código. Preciso sim, estender os métodos para que o pacote contenha também as variáveis da classe filha.

O pack, portanto, vai pegar o container da classe mãe, e vai empacotar em um novo container, junto com suas próprias variáveis.

public container pack()
{
    container base;

    base = super();

    return [#CurrentVersion, #CurrentList, base];
}

Já o unpack vai desempacotar o container em três partes: a versão, sempre a primeira variável, as variáveis da classe filha e um segundo container, contendo as variáveis da classe mãe. Este segundo container é passado para o unpack da classe mãe.

Veja sua utilização, funcionando perfeitamente:

    Employee    empregadoA;
    Employee    empregadoB;
    container   packed;
    ;
    
    empregadoA = new Employee();
    
    empregadoA.parmName("Jose");
    empregadoA.parmBirthdate(1\5\1950);
    empregadoA.parmHiringDate(10\5\1980);
    packed = empregadoA.pack();
    empregadoA = null;
    
    empregadoB = new Employee();
    empregadoB.unpack(packed);

    print empregadoB.parmName();
    print empregadoB.parmBirthdate();
    print empregadoB.parmHiringDate();
    
    pause;

Boas práticas para containers

Eduardo Miranda — Fri, 18 Jan 2008 14:36:56 GMT

SysDictCoder publicou um post sobre como utilizar melhor os containers: Dealing with containers. Como o próprio autor define "container é um poderoso, e um pouco estranho, tipo". Para mim pouco é gentileza dele, containers são muito estranhos. Um ponto que realmente me incomoda é a pouca legibilidade dos containers. É impossível saber o que tem dentro deles, quantos níveis, os tipos, nada. Você é obrigado a ler o código que criou um container para conseguir ler os dados dele.

Existem diversas estrutura de dados no X++ e podem ser ótimas alternativas: Arrays, Maps, List, Set, RecordSortedList, dentre outros. Ou seja, estamos bem servidos de estrutura de dados. Se, ainda assim você precisar utilizar containers, sugiro a leitura acima.

Práticas e padrões: Métodos parmVariable()

Eduardo Miranda — Fri, 18 Jan 2008 14:03:44 GMT

Variáveis de classe no X++ não aceitam “access modifiers” e são sempre privadas. Ou seja, uma variável declarada no class declaration só acessivel dentro da própria classe.

No C#, ou no VB, nós temos as propriedades para dar acesso externo as variáveis de classe. Já no Java é comum criar método GetVariavel e SetVariavel para isto. No X++ o padrão é criar um método parmVariavel que oferece ao mesmo tempo acesso de leitura e de escrita na variável.

A classe Person abaixo, por exemplo, tem duas variáveis de classe: name e birthDate

class Person
{
    str     name;
    date    birthdate;
}

Se preciso expor estas variáveis para o mundo externo, faço um método parm como este:

public str parmName(str _name = name)
{;
    name = _name;
    
    return name;
}

O método recebe como parâmetro opcional o nome. Cujo o valor default é o nome atual. Veja como é fácil, alterar e ler a variável:

    Person person;
    ;

    person = new Person('José', 21\2\1998);
    person.parmName('João');

    print person.parmName();
    pause;

Mesmo inicializando o objeto com o nome ‘José’, consigo alterar o nome para ‘João’. Agora em alguns casos não quero permitir alteração da variável, apenas leitura. Veja por exemplo o método parmAge, ele retorna a idade, baseado na data de nascimento. Só que não recebe parâmetro, pois esta é uma variável que não quero alterar.

public int parmAge()
{;
    return yearDiff(today(), birthDate);
}

A leitura do método continua normal.

static void Job1(Args _args)
{
    Person person;
    ;

    person = new Person('José', 21\2\1998);
    person.parmName('João');

    print person.parmName();
    print person.parmAge();
    pause;
}

Como boa prática só devemos expor as variáveis somente quando realmente precisamos usar. Neste post explico um pouco melhor o porque desta prática.

Acessando dados via X++

Eduardo Miranda — Tue, 16 Oct 2007 15:53:13 GMT

Uma das grandes vantagens do X++ como linguagem para um ERP são suas funcionalidades de acesso a dados integradas a própria linguagem. Isto simplifica bastante o acesso à camada de dados. Mesmo assim existem muitas formas de alcançar os mesmos objetivos, umas mais adequadas que outras. Neste post vou analisar algumas destas alternativas.

A estrutura mais utilizada de acesso aos dados de uma tabela é o while select. N exemplo abaixo seleciono e processo todos os clientes, contidos na tabela CustTable, que pertencem ao grupo “INTER-PR”.

    CustTable customer;
    ;

    while select customer
        where customer.CustGroup == "INTER-PR"
    {
        print strfmt("Id: %1 - Name: %2", customer.AccountNum, customer.Name);
    }

    pause;

Estendendo este código posso trazer as vendas abertas para estes clientes. O exemplo abaixo mostra isto, porém de uma forma pouco performática. Para cada cliente você faz um novo select na tabela de pedidos. Para uma base de 500 clientes, são 501 acessos ao banco de dados.

    CustTable customer;
    SalesTable sales;
    ;

    while select customer
        where customer.CustGroup == "INTER-PR"
    {
        print strfmt("Id: %1 - Name: %2", customer.AccountNum, customer.Name);

        while select sales
            where sales.CustAccount == customer.AccountNum
        {

            print strfmt("  Sales: %1 - amount to be invoiced: %2", sales.SalesId, sales.amountOrderedNotInvoiced());
        }
    }

    pause;

O código abaixo mostra uma solução usando um join entre as duas tabelas. O resultado é o mesmo, mas o acesso ao banco de dados é feito de uma vez. O que torna a solução mais performática.

    CustTable customer;
    SalesTable sales;
    CustAccount currentCustomer;
    ;

    while select customer
        where customer.CustGroup == "INTER-PR"
        join sales
            where customer.AccountNum == sales.CustAccount
    {
        if (customer.AccountNum != currentCustomer)
        {
            print strfmt("Id: %1 - Name: %2", customer.AccountNum, customer.Name);
            currentCustomer = customer.AccountNum;
        }

        print strfmt("  Sales: %1 - amount to be invoiced: %2", sales.SalesId, sales.amountOrderedNotInvoiced());
    }

    pause;

Outro problema muito comum é listar todos os clientes que têm ordens de venda em aberto. Uma solução que pode parecer razoável é esta abaixo. Para cada cliente verifico se existe uma ordem aberta para ele.

    CustTable customer;
    ;

    print "Clients with open orders:";
    while select customer
    {
        if (SalesTable::existCustOpenOrder(customer.AccountNum))
        {
            print strfmt("  Id: %1 - Name: %2", customer.AccountNum, customer.Name);
        }
    }

    pause;

Existem dois pontos fracos nesta solução: O primeiro select traz todos os clientes, sem filtrar nada. Depois disto, para cada cliente, um select é realizado na tabela de ordens de venda. Novamente um join é o mais adequado para este caso. Porém, neste caso, o ideal é fazer um tipo especial de join, que o exists join.

    CustTable customer;
    SalesTable sales;
    ;

    print "Clients with open orders:";
    while select customer
        exists join sales
        where customer.AccountNum == sales.CustAccount
    {
        print strfmt("  Id: %1 - Name: %2", customer.AccountNum, customer.Name);
    }

    pause;

Neste caso, o exists join tem uma grande vantagem sobre um join comum: Não traz todas as ordens de vendas de cada cliente. Com isto o resultado do select é menor (leia-se: quantas linhas retornam). Além disto, a instância da tabela de ordens de compras não é carregada, economizando memória.

Este tipo de join tem seu inverso, que é o notexists. O comando também é conhecido como “minus” em SQL, pois trazem as linhas da tabela de cliente MENOS os clientes que estão na tabela de ordens de venda. Este é o resultado do código abaixo.

    CustTable customer;
    SalesTable sales;
    ;

    print "Clients without open orders:";
    while select customer
        notexists join sales
        where customer.AccountNum == sales.CustAccount
    {
        print strfmt("  Id: %1 - Name: %2", customer.AccountNum, customer.Name);
    }

    pause;

Utilizando o notexists temos que tomar o seguinte cuidado. As cláusulas where referentes à tabela de clientes devem ser escritas logo abaixo do select. Já as cláusulas referentes ao join entre as tabelas ficam no final do comando. Se eu quiser, por exemplo, filtrar os clientes que estão em São Paulo, tenho a query abaixo. Dois where no mesmo select não é comum em SQL, mas a leitura é bem intuitiva: Quero buscar os clientes que estão em São Paulo (primeiro select) e que não têm ordens de venda (o join).

    CustTable customer;
    SalesTable sales;
    ;

    print "Clients without open orders:";
    while select customer
        where customer.State == "SP" //Neste where ficam as cláusulas referentes a customer
        notexists join sales
        where customer.AccountNum == sales.CustAccount //Neste ficam as cláusulas do join
    {
        print strfmt("  Id: %1 - Name: %2", customer.AccountNum, customer.Name);
    }

    pause;

Se você tentar colocar a cláusula do cliente no final, junto com as outras, verá que o resultado é o inverso, a query trará os cliente que não estão em São Paulo, pois a cláusula está relacionada ao notexists.

Como conclusão, seguem algumas dicas para identificar qual a melhor solução:

Se dentro do select while você está fazendo testes com campos da tabela ou buscando informações de outras tabelas, também usando informações da tabela, verifique se um join não pode resolver este problema.
Se você está fazendo um join, mas a segunda tabela só é utilizada como filtro para o select, verifique se é possível utilizar o comando exists ou notexists

Debugando aplicações em AX

Eduardo Miranda — Mon, 02 Jul 2007 14:26:04 GMT

Ótimas dicas de como debugar de forma mais eficiente no Dynamics AX neste post.

Estudando para a Certificação

Eduardo Miranda — Tue, 26 Jun 2007 16:48:27 GMT

O Carlos Nobrega me enviou um email perguntando sobre material disponível para estudo para a segunda prova de certificação de desenvolvimento no Dynamics AX. Segue a minha resposta abaixo, caso alguém mais tenha interesse.

Carlos,

Não existe muito material disponível na internet sobre AX, como você deve ter percebido (se comparado com .Net ou Java).
Se a empresa que você trabalha tem acesso ao PartnerSource você pode pegar o material dos cursos.
Este link apresenta o que cairá na prova (provavelmente vc já conhece):
https://mbs.microsoft.com/partnersource/communities/training/Certifications/exampreparation/AX4Morph_prep.htm
Você pode pegar o material dos cursos 1 a 4
https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student/course8623
https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student/course8633
https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student/course8645
https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student/course8643

Neste link você pode procurar e baixar o material de qq curso:
https://mbs.microsoft.com/partnersource/communities/training/trainingmaterials/student

Para X++ tem o livro do Luis Mourão que, apesar de ser sobre o AX 3.0, é o mais completo em relação a linguagem. Talvez você ache o capítulo de X++ disponível na internet.
http://www.amazon.com/Dynamics-AX-Guide-Microsoft-Axapta/dp/1590594894
Boa sorte,

Novo blog sobre X++

Eduardo Miranda — Mon, 25 Jun 2007 20:15:56 GMT

Através do blog o Michael descobri que o time do compilador X++ criou um novo blog e já está escrevendo.

Utilizando maps para reaproveitamento de código

Eduardo Miranda — Thu, 24 May 2007 20:22:13 GMT

O Dynamics AX tem um objeto não muito comum em linguagens OO, mas que permite mapear suas Tables com um funcionamento semelhante ao de uma interface. Vou mostrar um exemplo simples como aplicar esta funcionalidade.

A SalesTable, que contém as ordens de venda, e a PurchTable, que contém as ordens de compra, têm alguns campos em comum e podem ter algumas funcionalidades em comum. Por isto existe no sistema um Map, chamado SalesPurchTable, que mapeia alguns campos destas tabelas e pode ser usado em métodos cuja regra de negócio é comum as duas tabelas.

Como é possível ver na imagem um Map é composto de campos, grupos de campos, métodos e mappings. Estes mapeiam cada campo do Map ao campo correspondente da tabela. Você pode perceber que o map SalesPurchTable mapeia não só a SalesTable e PurchTable, mas também SalesBasket, SalesQuotationBasket e SalesQuotationTable.

Uma forma interessante de utilizar o Map é evitar a duplicação de código, quando existe uma funcionalidade igual, ou muito parecida, mas que usam diferentes tabelas.

O código de exemplo abaixo implementa uma classe e um método printOrderDetails. O método recebe como parâmetro um map SalesPurchTable. O método é bem simples, imprime alguns campos da ordem. O importante é que ele pode receber tanto objetos do tipo SalesTable como do tipo PurchTable que o seu comportamento será igual.

static void printOrderDetails(SalesPurchTable _table)
{;

    print _table.SalesPurchId;
    print _table.OrderAccount;
    print _table.CashDisc;
    
    pause;
}

O job abaixo executa o nosso método passando um SalesTable e em seguida um PurchTable e o comportamento é igual.

static void Job11(Args _args)
{
    SalesTable salesTable;
    PurchTable purchTable;
    ;

    //Trocar o parâmetro para uma id de Sales Order válido
    salesTable = SalesTable::find('000004'); 
    //Trocar o parâmetro para uma id de Purchase Order válido
    purchTable = PurchTable::find('000001'); 
    
    MapSample::printOrderDetails(salesTable);
    MapSample::printOrderDetails(purchTable);
}

Quem conhece um pouco mais de X++ sabe que posso obter um resultado semelhante com o tipo common, pois ele aceita qualquer objeto. Mas a solução utilizando Map tem uma grande vantagem: Ela é Type safe. Veja na imagem abaixo o que acontece se tento passar um objeto do tipo SalesLine para o método. Ocorre um erro em tempo de compilação, pois não existe mapping de SalesLine para SalesPurchTable. Utilizando o common este mesmo erro ocorreria em tempo de execução, o que é muito pior.

Se durante a execução do código você precise saber qual tipo da tabela recebida ainda assim é possível, como você pode ver no código abaixo.

O que você NÃO deve fazer é criar um método que recebe um map, mas no final das contas tem um comportamento completamente distinto para cada tipo de tabela. Neste caso o seu método fica muito grande, com muitas responsabilidades e confuso para os outros desenvolvedores lerem.

static void printOrderDetails(SalesPurchTable _table)
{;

    switch (_table.TableId)
    {
        case TableNum(SalesTable):
            print "Sales Order";
            break;
            
        case TableNum(PurchTable):
            print "Purchase Order";
            break;
            
        default:
            print "Order";
            break;
    }

    print _table.SalesPurchId;
    print _table.OrderAccount;
    print _table.CashDisc;
    
    pause;
}

Links interessantes

Eduardo Miranda — Thu, 24 May 2007 13:53:31 GMT

Existem alguns blogs que falam sobre AX por ai, não muitos. Seguem alguns posts que achei interessantes recentemente:

Tips & Tricks - Label lookup

Eduardo Miranda — Mon, 23 Apr 2007 17:29:05 GMT

É uma boa prática utilizar labels ao invés de textos "hard coded" no AX. No entanto muitas vezes a leitura do código-fonte fica prejudicada. Qual a mensagem que o usuário verá se este trecho de código for executado?

A boa notícia é que existe um atalho para você ir direto para o label escrito no código. Basta marcar o label, clicar com o botão direito do mouse e selecionar "Lookup Label/Text"

Label editor se abrirá já com o label selecionado marcado, permitindo inclusive a alteração do label.