CREATE TABLE "estado"
(
"id" NUMBER  NOT NULL,
"nome" VARCHAR2(50),
"sigla" VARCHAR2(2)
);

MySQL e PostgreSQL não apresentaram problemas. Porém, a inserção deste SQL no Oracle força que todas as tabelas e campos sejam criados na forma de caracteres minúsculos.

Ou seja, se você fizer uma consulta diretamente no banco¹ da seguinte forma:

SELECT nome FROM estado;

Receberá um erro informando que a tabela não existe! Apenas nesta forma funcionaria:

SELECT "nome" FROM "estado";

Conseqüentemente, todas as consultas efetuadas através dos objetos de mapeamento do banco geradas pelo Propel não funcionarão. A solução foi simples: remover as aspas duplas do arquivo SQL gerado (utilizei a ferramente rpl do linux):

rpl '"' '' data/sql/*

Uma solução não muito adequada, mas resolveu. Até que resolvi consultar a lista symfony-users sobre o problema e um integrante, Charley Tiggs, sugeriu a seguinte configuração no propel.ini:

propel.disableIdentifierQuoting = true

Simples e funcional. Fica a referência para consultas futuras

¹ Sugiro o Oracle SQL Developer, uma ótima ferramenta GUI desenvolvida em Java para acessar bancos em Oracle, MySQL e SQL Server. Sendo uma ferramenta Java, pode ser executada perfeitamente no Linux, como estou utilizando aqui!

Por exemplo:

project:
id:
title: varchar(255)
sf_guard_user_id:

O código acima resultará no seguinte erro:

“Unable to resolve foreign table for column “sf_guard_user_id”"

Pesquisando sobre o assunto, uma sugestão seria alterar o namespace onde são gerados os arquivos de ORM do Propel. Particularmente, não achei interessante. Na lista symfony-users, uma referência diz que essa é uma limitação do Propel.

A verdade é que a “solução” é extremamente simples:

project:
id:
title: varchar(255)
user_id: { type: integer, foreignTable: sf_guard_user, foreignReference: id, required: true, onDelete: cascade }


Supondo um endereço de intranet, o WSDL deste webservice estaria disponível na URL:

• http://intranet/sugarcrm/soap.php?wsdl

Este how-to abrange a integração do SugarCRM com o Symfony. Neste cenário, uma aplicação deve manter os mesmos registros de contas (Accounts) que existem no SugarCRM. Vamos apenas gerar um array onde a chave será o ID da conta e o valor será o nome da conta.

Uma curiosa surpresa ao iniciar a integração foi descobrir que havia um plugin para o Symfony chamado sfSugarCRM, constituído de duas classes:

• sfSugarCRMSOAPClient: Classe com um método no padrão Singleton que retorna a instância de SoapClient conectada ao WSDL do SugarCRM.
• sfSugarCRM: Classe que abstrai algumas requisições ao Webservice do SugarCRM.

Importante: este plugin não utiliza NuSOAP, mas sim as bibliotecas SOAP distribuídas nas versões do PHP5 e posteriores. Certifique-se que a extensão SOAP está instalada.

Inicialmente, seguindo a breve documentação de exemplo do sfSugarCRM, vamos instalar o plugin:

./symfony plugin-install http://plugins.symfony-project.com/sfSugarCRMPlugin
./symfony cc

Pulemos os passos de criação da aplicação e do módulo no Symfony, o código abaixo conecta ao Webservice:

$sugar = new sfSugarCRM("http://intranet/sugarcrm/soap.php?wsdl");
$sugar->setUsername("usuario");
$sugar->setPassword("senha");

O trecho acima armazena o usuário e a senha em variáveis de instância, e as utiliza para a chamada de alguns métodos do servidor SOAP, que são:

• Localizar contatos pelo nome: searchContactsByName()
• Localizar contatos pelo e-mail: searchContactsByEmail()
• Retornar lista de usuários: getUserList()
• Métodos para criação de registros: createLead(), createContact(), createAccount(), createOpportunity(), createCase()

Um detalhe a importante é que os métodos acima enviam usuário e senha a cada requisição ao Webservice. Alguns métodos do Webservice, entretando, exigem como parâmetro o ID do login, uma string gerada com a chamada ao método login() do Webservice. Como a classe sfSugarCRM não implementa nenhum método para isso, abaixo um patch que cria essa função:

• Patch sfSugarCRM

Para aplicar o patch, entre na raiz do projeto e digite:

patch -p0 < patch.txt

Após aplicado o patch, você tem os novos métodos na classe sfSugarCRM: getLoginId() e doLogin() , que facilitam a chamada para diversos métodos do Webservice. Dessa forma, é só criar novos métodos na classe sfSugarCRM! Criei um método chamado getEntryList() (que utiliza o método get_entry_list() do webservice), veja como retornar todos os clientes:

$params = array(
  "module_name" => "Accounts",
  "order_by" => "name ASC",
  "offset" => 0,
  "select_fields" => array("name"),
  "max_results" => 1000
);
$sugar->getEntryList($params);
$response = $sugar->getResponse();
$contas = array();
foreach ($response->entry_list as $entry) {
    $contas[$entry->id] = $entry->name_value_list[0]->value;
}
print_r($contas);

Então é isso! Este material não será de uso constante, mas fica como referência quando um cenário semelhante surgir

Referências:

• SugarCRM SOAP Overview (.rtf)
• PHP Soap Extension
• Symfony plugins: sfSugarCRM
• Soap Intro and pratical examples