Integração: mas somente quando o pedido mudar de status/estado

Como podemos disparar um evento ou integração sempre que um pedido mudar de status ou estado?

Esta foi a dúvida de um aluno do Curso de Criação de Módulos e Desenvolvimento Backend para Magento 1.x no nosso grupo de alunos. Vamos ver aqui uma das formas de se atingir este objetivo.

Eventos: O Básico

O Magento usa uma arquitetura de eventos. Em outras palavras, em vários pontos do seu código, eventos são disparados. Módulos que “escutam” esses eventos podem então interagir com o que está acontecendo. Idealmente de forma passiva, mas também podem modificar objetos e dados que estão ali. Isso é feito através de “observers“, que como o nome sugere, observam eventos específicos.

Um status de pedido pode ser alterado em vários momentos do fluxo de compras. Criar múltiplos observers (aula 31) para cobrir todos pode ser um pouco demorado, e ainda podemos deixar passar alguma coisa.

A primeira coisa que fiz

Sempre que vejo uma situação como esta, busco a classe ou observer que está mais próximo do momento que a gravação dos dados ocorre no banco de dados. Desta forma, se algum módulo sobrescreveu um Model, usou outro evento, ou fez a atualização em algum lugar que eu não previ, geralmente estou coberto.

Eventos no Magento 1.x são disparados através da chamada do método dispatchEvent. Sendo assim, fiz uma busca geral pela chamada do método mas que contivessem a palavra ‘save’ no seu primeiro parâmetro. Para isso usei expressão regular, direto na minha IDE.

Isso também pode ser feito usando grep (grep -iR "dispatchEvent\(.*save" ./app/code/core).

Logo encontrei um possível candidato, como pode ver na imagem acima.

Criando módulo para escutar as alterações

Depois de um pouco de log e xdebug, pude ver que o observer dinâmico, logo abaixo do ‘model_save_before’ mostrado acima poderia ser um bom candidato. Só precisava descobrir o que seria usado no meu $this->_eventPrefix.

Os passos seguintes foram basicamente:

• Criar um módulo básico
• Criar um observer para o evento ‘sales_order_save_before‘
• Gravar um log de exemplo apenas quando o state ou status do pedido fosse alterado

O Resultado

        <events>
            <sales_order_save_before>
                <observers>
                    <magenteiro_testchangestatus>
                        <type>model</type>
                        <class>magenteiro_testchangestatus/observer</class>
                        <method>beforeModelSave</method>
                    </magenteiro_testchangestatus>
                </observers>
            </sales_order_save_before>
        </events>

class Magenteiro_TestChangeStatus_Model_Observer
{
    public function beforeModelSave($observer)
    {
        $old = $observer->getOrder()->getOrigData('status') . '/' . $observer->getOrder()->getOrigData('state');
        $new = $observer->getOrder()->getData('status') . '/' . $observer->getOrder()->getData('state');

        if ($new != $old) {
            Mage::log('status/state antigo: ' . $old, null, 'martins.log', true);
            Mage::log('status/state novo: ' . $new, null, 'martins.log', true);
        }
    }
}

Como podemos ver, agora temos acesso não apenas a todos os dados do pedido sendo alterado, como também aos dados originais (antes da alteração).

Outras finalidades:

Você pode usar a abordagem acima em outras entidades e assim alcançar outros objetivos. Por exemplo:

• Criar um módulo de auditoria para ver quem alterou e quando alterou um pedido
• Usar o mesmo princípio para auditar outras alterações nas entidades do Magento
• Realizar integrações que só devem acontecer na alteração de um pedido

Download do módulo acima

Se preferir, faça download do módulo de exemplo acima.

Para instalar o módulo, basta descompactar o conteúdo e copiar a pasta app para sua pasta raiz do Magento 1.x.

Toda vez que um pedido mudar de status ou estado, a informação será adicionada no arquivo var/log/martins.log.

Modifique-o para atender suas necessidades de integração.

E no Magento 2?

Nós já abordamos uma integração de estoque no Magento 2 de forma bem parecida. A vantagem é que no Magento 2 temos os Plugins.

Como eles nos permitem injetar códigos em praticamente qualquer lugar (sem depender de eventos disponíveis), podemos fazer isso direto no ResourceModel.

Estas são classes de um nível ainda mais próximo ao momento da gravação dos dados no banco. Desta forma temos ainda mais certeza de estar abordando qualquer tipo de alteração de dados, independente de onde elas ocorram.

Mesmo assim, ainda é possível criar eventos e observers também no Magento 2.x. Mas já falamos sobre isso aqui no blog e no curso de Magento 2 também.

• Sobre
• Últimos Posts

Ricardo Martins

É desenvolvedor web há 16 anos e um dos primeiros certificados pela Magento no Brasil. Instrutor de mais de 11 cursos Magento (os principais no magenteiro.com/cursos) com mais de 14 mil alunos de 105 países, é também criador do módulo PagSeguro Transparente, usado em mais de 12 mil lojas.

Últimos posts por Ricardo Martins (exibir todos)

• PagSeguro (PagBank) para Magento 1 recebe a Nova Geração - 9 de abril de 2024
• Recorrência no WooCommerce Sem Plugins Pagos - 28 de janeiro de 2024
• Chargeback. O que é, e como se livrar deles. - 19 de dezembro de 2023