BRPI0609334A2 - gerenciamento de dados para sistema de dados móvel - Google Patents

Abstract

GERENCIAMENTO DE DADOS PARA SISTEMA DE DADOS MóVEL. Uma arquitetura de dados provê clientes moveis com a capacidade de ter acesso a fontes de dados de empresa comerciais através de Visualizaçóes configuráveis que realizam interface com as fontes de dados através de Objetos de dados que são definidos por Comandos, que por sua vez se comunicam com as fontes de dados através de Conectores (também mencionados como Adaptadores) . Cada tipo de Visualização fará interface com as fontes de dados com uma funcionalidade diferente de modo que links de comunicação e outros recursos de sistema possam ser utilizados de forma mais eficiente. Os tipos de Visualização podem incluir Visualizações diretas, Visualizações derivadas, Visualizações delegadas, e Visualizações de definição.

Description

GERENCIAMENTO DE DADOS PARA SISTEMA DE DADOS MÓVEL

REFERÊNCIA A DOCUMENTOS DE PRIORIDADE

O presente pedido reivindica beneficio deprioridade de: pedido de patente provisional US número desérie 60./664.121 intitulado "Data Management for Mobiledata system", de Robert 0'Farrell e outros, depositado em21 de março de 20C5; pedido de patente provisional UScopendente número de série 60/664.088 intitulado "ModularApplications for Mobile data system," por Robert Loughan,depositado em 21 de março de 2005; pedido de patenteprovisional US copendente número de série 60/664.122intitulado "Adapter architecture for mobile data system",por Robert O'Farrell e outros, depositado em 21 de março de2005; e pedido de patente provisional US copendente númerode série 60/667.816 intitulado "Modular ApplicationsManagement for mobile data system", por Robert 0'Farrell eoutros, depositado em Io de abril de 2005. A prioridadedas respectivas datas de depósito é pela presentereivindicada, e as revelações desses pedidos de patenteprovisionais são pela presente incorporadas a titulo dereferência.

AVISO DE DIREITOS AUTORAIS

Uma parte da revelação desse documento de patentecontém material que está sujeito à proteção de direitosautorais. O proprietário de direitos autorais não fazobjeção à reprodução por fax por qualquer pessoa, dodocumento de patente ou revelação de patente conformeconsta no depósito ou registros de patente do Departamentode Patentes e Marcas Registradas dos Estados Unidos daAmérica, porém reserva de outro modo todos os direitosautorais.

ANTECEDENTES1. Campo da Invenção

A presente invenção refere-se genericamente asistemas de computação móveis e, mais particularmente, agerenciamentos de dados e uso de dados em sistemas decomputação móveis.

2. Descrição da técnica relacionada

Sistemas de gerenciamento de relação de cliente(CRM) e planejamento de recursos de empresa (ERP),sofisticados, são disponíveis para melhorar a automatizaçãode processos de back office e de front office. Emboramuitas companhias tenham realizado significativas economiase eficiências a partir do uso de tais sistemas, éverdadeiro também que muitas organizações acham que ossistemas são incômodos de implementar e difíceis deintegrar com sistemas de dados de legado existentes.

Mais recentemente, organizações comerciais eempresas estão usando sistemas CRM e ERP para auxiliar osfuncionários móveis, principalmente a utilizar dispositivosde computação móveis como pagers e telefones celulares etambém assistentes pessoais digitais (PDAs). Umimpedimento importante para maior adoção de sistemas CRM eERP que empregam tais dispositivos móveis, envolve aintegração com outros dados na empresa.

As questões de integração de dados de empresapodem se originar porque as aplicações móveisfreqüentemente vêm em arquiteturas fechadas, depropriedade, que impedem integração com.outros sistemas dedados da empresa. Por exemplo, dados na empresa poderiamser mantidos em quatro ou cinco fontes diferentes. Algumasdas fontes de dados incluem sistemas CRM, sistemas dedespacho, sistemas ERP, e sistemas de registrosfinanceiros. Cada uma dessas fontes de dados pode utilizaruma arquitetura de dados diferentes, formato e protocolo.Os dados sendo armazenados e a configuração dos dados e mecanismos de acesso estão constantemente mudando. Muitos sistemas de computação móveis criam um armazenamento de dados interino no qual dados a partir de várias fontes na empresa são coletados. Desse modo, dados a partir de diferentes fontes de dados de empresa, cada com uma arquitetura e formato de dados diferentes, podem ser coletados em um único banco de dados comum. Os usuários móveis podem acessar os dados de empresa acessando '.o armazenamento de dados interino, em vez das fontes de dados de empresa efetivas. 0 armazenamento interino, entretanto, cria questões de conflito e atualização de dados próprios.

As operações de sincronização e outras proteções devem ser executadas freqüentemente, para assegurar que os dados no armazenamento de dados interino são uma cópia fiel dos dados nas fontes de dados de empresa.

É conhecida a provisão de uma solução de integração de dados que pode utilizar dispositivos de computação móveis que realizam a interface com fontes de dados de empresa através de um servidor de rede. Tal sistema é descrito no pedido de patente US número de série 10/746.229 depositado em 23 de dezembro de 2003 cedida a Dexterra, Inc., de Bothell, Washington, EUA. O teor desse pedido é incorporado aqui a titulo de referência.

O pedido de patente de Dexterra, Inc. descreve um sistema no qual dados são utilizados entre múltiplas fontes de dados de empresa para clientes móveis em um modo distribuído de tal modo que solicitações de um cliente móvel para os dados de empresa sejam recebidas, as fontes de dados de empresa apropriadas contêm os dados solicitados são determinadas, e os dados de empresa são recuperados das fontes de dados de empresa, determinadas. Quando os dados de empresa são recuperados, os mesmos são convertidos em umformato relacionai, mesmo se os dados vêm de múltiplas fontes de dados de empresa de diferentes tipos não relacionais (por exemplo, Sistema de Arquivo, e-mail, etc.)- Os dados de empresa convertidos são armazenados em um armazenamento de dados relacionai no cliente móvel. Desse modo, aplicações móveis podem ser totalmente integradas com dados a partir de múltiplas fontes de dados de empresa e atualizações de dados e alterações de configuração podem ser distribuídas para e a partir de clientes móveis em tempo real, sem utilizar armazenagem de dados interina, e desse modo evitando questões de dados assincronos e sincronização completada entre as fontes de dados de empresa e os clientes móveis. As alterações de dados em tempo real podem incluir uso de alterações na própria aplicação móvel, bem como atualizações de dados. As alterações em tempo real são adicionalmente acomodadas com detecção de conflito de dados e resolução.

O sistema da Dexterra, Inc. referenciado acima se baseia em uma arquitetura de sistema na qual fontes de dados de empresa alvo contêm objetos ou tabelas de dados, e cada tabela de dados alvo é mapeada em um obj et o de dados denominado Visualização. Isto é, uma Visualização é definida que corresponde a cada tabela de dados nas fontes de dados de empresa a partir da qual a aplicação obterá dados. As Visualizações podem ser definidas pelo

desenvolvedor de aplicador, ou a partir de outro vendedor. Os dados nas Visualizações são compartilhados entre uma ou mais entidades de dados mencionadas como Obj etos comerciais. Um único Objeto comercial pode utilizar dados a partir de múltiplas Visualizações, e portanto pode utilizar dados a partir de múltiplas fontes de dados de empresa, mesmo a partir de fontes de dados que têm formatos de dados incompatíveis. No sistema, obj etos de dadosdenominados Conectores fornecem uma interface de compartilhar dados com as fontes de dados de empresa.

Após definição de um conjunto de Objetos Comerciais, desenvolvedores de aplicação podem projetar aplicações enquanto lidam com dados através de sua interface com os Objetos Comerciais, em vez de se envolverem na descrição e definição das Visualizações e Conectores - Desse modo, desenvolvedores são apresentados com uma interface de dados de formato livre, de modo que diferenças em alvos são extraídas do desenvolvedor.

O sistema descrito no pedido de patente da Dexterra, Inc. referenciado acima, prove uma ferramenta de desenvolvimento poderosa para a plataforma de computação móvel que permite acesso a uma variedade de fontes de dados de empresa. Adaptabi1idade ainda maior na configuração dos dados de Visualização, entretanto, poderia estender as capacidades do sistema e fornecer flexibilidade maior. A presente invenção prove essas capacidades de configuração de Visualização, maiores.

SUMÁRIO

De acordo com a invenção, clientes móveis têm acesso a fontes de dados de empresa comerciais através de Visualizações configuráveis que realizam interface com as fontes de dados através de Obj et os de dados que são definidos por Comandos, os quais por sua vez se comunicam com as fontes de dados através de Conectores (também referenciados como Adaptadores) . Cada tipo de Visualização fará interface com as fontes de dados com uma funcionalidade diferente de modo que links de comunicações e outros recursos de sistemas possam ser utilizados mais eficientemente. Por exemplo, os tipos de Visualização podem incluir Visualizações diretas, Visualizações derivadas, Visualizações delegadas, e Visualizações dedefinição. Esses novos tipos de Visualização podem fornecer maior controle sobre interfaces de dados e podem ser configurados para maior utilização de recursos de sistema.

Visualizações diretas são Visualizações que recuperam dados diretamente de uma fonte de dados de empresa. Visualizações derivadas solicitam dados a partir de um servidor que recupera um con j unto base de dados associados em tempo de execução a^ partir das fontes de dados de empresa e então coloca os dados recuperados em um motor de dados relacionai (RDE) que aplica parâmetros de filtro de Visualização derivada para extrair dados filtrados e fornecer os mesmos ao tipo de Visualização Derivada solicitante. A Visualização delegada recuperará periodicamente dados a partir das fontes de dados de empresa e colocará os dados recuperados em um cache de Motor de dados relacionai a partir do qual solicitações subseqüentes de clientes móveis para dados de empresa podem ser preenchidas, desse modo reduzindo o tráfego de dados entre o cliente móvel e as fontes de dados. A Visualização de Definição permite controle sobre onde os dados recuperados são mantidos, quer no servidor do sistema ou no cliente móvel, desse modo estendendo o controle sobre utilização dos recursos do sistema.

Outras características e vantagens da presente invenção devem ser evidentes a partir da seguinte descrição da modalidade preferida, que ilustra, como exemplo, os princípios da invenção.

BREVE DESCRIÇÃO DOS DESENHOS

A figura 1 é um diagrama de blocos de um ambiente de sistema de computador apropriado para uma plataforma de empresa móvel construída de acordo com a presente invenção.A figura 2 é um diagrama de blocos da arquitetura lógica de dados na plataforma de empresa móvel ilustrada na figura 1.

A figura 3 é um diagrama de blocos que ilustra a interface de Conector entre as fontes de dados de empresa e o cliente móvel da figura 1.

A figura 4 é um diagrama de blocos de um ambiente de sistema de computador apropriado, 400, construído de acordo com a presente invenção.

A figura 5 é uma representação diagramática do fluxo de dados de Visualização derivada utilizando a arquitetura de Visualização de acordo com a presente invenção.

A figura 6 mostra uma representação diagramática da arquitetura de dados para a plataforma móvel ilustrada na figura 1.

A figura 7 é uma representação diagramática da configuração de acesso de dados para a plataforma móvel construída de acordo com a presente invenção.

A figura 8 é uma foto de tela de um display em um dispositivo de computador que está hospedando a aplicação de programa do computador DAD.

A figura 9 mostra uma visualização de árvore e menu de contexto gerado pelo programa DAD quando "Tipos de fontes de dados" é selecionado no menu Dexterra Explorer.

A figura 10 mostra a seleção do item do menu de Fontes de dados a partir do display da figura 9.

A figura 11 mostra a seleção de um tipo especifico de fonte de dados, a partir do qual um menu de contexto é gerado.

A figura 12 mostra tipos de Visualização que são disponíveis para seleção.A figura 13 mostra uma caixa de diálogo de Propriedades de Fontes de dados que é gerada pela utilização de um menu de contexto de Fontes de dados para criar um novo tipo de Fontes de dados.

A figura 14 mostra uma tela de autenticação para informações de registro de DAD e escolher um alvo de fonte de dados de empresa especifico.

A figura 15 mostra um projetista fazendo uma seleção de Comando a partir da visualização de árvore.

A figura 16 mostra uma caixa de diálogo de "Novo comando" em resposta à seleção na figura 15.

A figura 17 mostra o tab Parâmetros do diálogo Adicionar comando.

A figura 18 mostra a visualização de árvore com um novo Comando denominado "CustomerQuery" que foi adicionado.

A figura 19 é um diagrama de fluxo que ilustra operações de um sistema de computador de acordo com a presente invenção.

DESCRIÇÃO DETALHADA

Em um sistema de integração de dados móvel, construído de acordo com a invenção, clientes móveis rodando uma interface de aplicação com fontes de dados de empresa através de obj etos de Visualização configuráveis que acessam dados através de Obj etos de dados que são definidos em temos de Obj etos de Comando que realizam interface com as fontes de dados de empresa através de Adaptadores (também denominados Conectores). Os múltiplos tipos de Visualizações que são suportados podem fornecer maior capacidade de adaptação para desse modo estender as capacidades do sistema e fornecer maior flexibilidade. Cada tipo de Visualização fará interface com as fontes de dados com uma funcionalidade diferente de modo que links decomunicações e outros recursos de sistema possam ser utilizados de forma mais eficiente.

Como descrito adicionalmente abaixo, na modalidade ilustrada, os tipos de Visualização incluem Visualizações diretas, Visualizações derivadas,

Visualizações definidas e Visualizações designadas. Uma Visualização direta recuperará dados diretamente de uma fonte de dados de empresa através de Objetos de dados, Comandos e Adaptadores. Uma Visualização derivada

incorporará parâmetros de filtro e solicitará dados a partir de um servidor que recupera um conjunto base de dados associados em tempo de execução a partir das fontes de dados de empresa e então coloca os dados recuperados em um motor de dados relacionai (RDE) que aplica os parâmetros de filtro de Visualização derivada para extrair dados filtrados e fornecer os mesmos ao tipo de Visualização derivada solicitante. A Visualização delegada recuperará periodicamente dados a partir das fontes de dados de empresa de acordo com parâmetros da Visualização delegada e colocará os dados recuperados em um cache de Motor de Dados relacionai. Solicitações subseqüentes a partir de clientes móveis para dados de empresa podem ser preenchidas obtendo os dados solicitados a partir do cache RDE em vez de diretamente das fontes de dados de empresa, desse modo reduzindo o tráfego de dados entre o cliente móvel e as fontes de dados. Dados atualizados a partir de clientes móveis são retornados diretamente às fontes de dados de empresa através dos Adaptadores. Uma Visualização de definição permite controle sobre onde os dados recuperados são mantidos, quer no servidor do sistema ou no cliente móvel. A extensão de recursos do sistema determinará genericamente a seleção entre as duas configurações.Uma configuração de base de uma arquitetura de sistema de base exemplar é descrita abaixo com relação às figuras 1, 2 e 3. Na modalidade preferida de um sistema de dados de cliente móvel que incorpora os objetos de Visualização configuráveis da presente invenção, o sistema utiliza uma arquitetura de Adaptador-Comando-Objeto de dados. O Adaptador-Comando-Objeto de dados é descrito adicionalmente abaixo em termos de alterações arquiteturais a partir do sistema das figuras 1, 2 e 3 em "V. Arquitetura de Adaptador" em combinação com a figura 4. Os objetos de Visualização configuráveis são descritos em maior detalhe abaixo em "VI.Tipos de visualização" em combinação com a figura 5.

I. VISÃO GERAL DO SISTEMA

A presente invenção prove um sistema no qual dados são utilizados a partir de múltiplas fontes de dados de empresa para clientes móveis executando aplicações móveis de tal modo que as aplicações móveis são integradas com as múltiplas fontes de dados de empresa, e atualizações de dados e alterações de configuração podem ser distribuídas para e recebidas a partir de clientes móveis em tempo real, sem utilizar armazenagem interina de dados. A eliminação de uma instalação de armazenagem interina de dados evita questões de dados assincronos e sincronização complicada entre as fontes de dados de empresa e os clientes móveis. Desse modo, atualizações de dados e atualizações de configuração do sistema para a aplicação móvel podem ser comunicadas a partir da empresa para os clientes móveis, e a partir dos clientes móveis para a empresa, em tempo real. Nenhuma operação de sincronização especial é necessária, visto que as alterações podem ser propagadas através do sistema em tempo real.

II. PLATAFORMA DO SISTEMAA figura 1 é um diagrama de blocos de um ambiente de sistema de computador apropriado 100 construído como descrito no pedido de patente da Dexterra, Inc., acima referenciado. De acordo com a presente invenção, a figura 1 mostra um dispositivo de cliente móvel 102, como um dispositivo de Assistente Pessoal digital (PDA) que opera em combinação com os sistemas operacionais Palm PDA ou PocketPC da Microsoft. O dispositivo de cliente móvel comunica-se através de uma conexão de rede 104 com um servidor de aplicação 106 para solicitar dados a partir do servidor e receber atualizações de dados, fornecer novos dados, e receber alterações de configuração. Deve ser entendido que múltiplos clientes móveis 102 podem se comunicar com o servidor 106. Somente um único dispositivo de cliente 102 é mostrado na figura 1 para fins de simplicidade de desenho.

Os clientes móveis 102 consomem os serviços de rede de conector do lado do servidor para recuperação de dados em tempo real a partir de múltiplos armazenamentos de dados de empresa. Adicionalmente, os clientes móveis consomem os serviços de rede de gerenciador de dados do lado do servidor para o gerenciamento' de atualizações de dados do lado de cliente em tempo real, atualizações de dados do lado de servidor e atualizações de configuração do sistema.

O servidor de aplicação 106 comunica-se com fontes de dados de empresa 108, como fontes de dados CRM, fontes ERP, recursos do sistema financeiro, armazenamentos de dados de legado, e similares. As fontes de dados de empresa exemplares, ilustradas na figura 1, incluem dados incluindo software "Siebel" a partir da Siebel Systems, Inc. de San Mateo, Califórnia, EUA; software "Oracle" a partir da oracle Corporation de Redwood Shores, Califórnia,EUA; software "SAP" a partir da SAP AG de Walldorf, Alemanha; e software de legado. A aplicação do

administrador 110 e uma aplicação de desenvolvedor 112 se comunicam com o servidor de aplicação 106, os quais também armazenam metadados 114 para o sistema, como descrito adicionalmente abaixo.

O servidor de aplicação 106 prove gerenciador de dados, configuração, e serviços de rede de conector de dados para intercâmbio de dados e atualização, autenticação de usuário, segurança e serviços de registro. O servidor de aplicação também manipula gerenciamento de processo comercial na forma de informações comerciais e regras.

O cliente móvel 102 também inclui um armazenamento de dados 116 que inclui uma base de dados relacionais 118 que armazena dados comerciais 120 e também uma base de dados relacionais que armazena metadados 122 para execução de aplicação no cliente móvel. Uma aplicação 124 que é instalada no cliente móvel 102 inclui vários componentes de software que executam funções apropriadas. Por exemplo, a aplicação poderia compreender uma aplicação de serviço de campo que informa ao pessoal de serviço de campo sobre um local no qual serviço foi solicitado, explica a natureza da solicitação de serviço, e prove registro da visita de serviço e quitação da conta. A aplicação 124 pode incluir múltiplas aplicações que processam os dados solicitados pelo cliente móvel 102.

A aplicação de administrador 110 e aplicação de desenvolvedor 112 juntos compreendem um componente de "Estúdio" 130. Na modalidade ilustrada, o administrador e desenvolvedor são fornecidos como duas aplicações separadas, e fornecem um meio para configurar o sistema, incluindo os dados de metadados e interfaces de aplicação.O sistema 100 compreende uma plataforma de empresa móvel que suporta a aplicação de serviço 124. O sistema prove um conjunto de serviços de Rede que usam e gerenciam, de forma eficaz, soluções de software mobilizado para aperfeiçoar os processos comerciais móveis. Os exemplos comuns incluem integrar a CRM ou ERP, automação de força de vendas (SFA), e funções de suporte ao cliente e balcão de aj uda para uma empresa. Tais aplicações de empresa dependem da interação de aplicação cruzada, em que dados a partir de uma função ou sistema são freqüentemente utilizados por uma função ou sistema diferente. Quando executado no cliente móvel, a funcionalidade de aplicação existente e informação de empresa são utilizadas entre múltiplas aplicações de software de empresa, sistemas de dados de legado, e trabalhadores móveis. Desse modo, um retorno significativo sobre o investimento pode ser obtido para essas aplicações e para a plataforma de empresa móvel.

A plataforma de empresa móvel 100 prove serviços de Rede que simplificam o uso de clientes móveis e dispositivos portáteis associados no campo. Esses serviços de rede incluem uma função de gerenciador de dados, uma função de configuração e uma função de conector. Essas serão descritas em maior detalhe abaixo. As aplicações 124 que são instaladas nos clientes móveis 102 podem ser totalmente funcionais em qualquer estado conectado ou desconectado, após terem sido adequadamente iniciadas pelo servidor de aplicação 10 6.

III. ARQUITETURA LÓGICA

Qualquer aplicação de cliente que faz uso da Plataforma de Empresa Móvel ilustrada na figura 1 utilizará os componentes do sistema ilustrados no diagrama de blocos da figura 2. Esses componentes incluem:Obj etos comerciais - objetos programáveis baseados em conceitos comerciais, combinando campos e relacionando informações de fontes de dados de empresa diferentes (por exemplo, fontes de dados como Cliente, Contatos, Bens, Tarefas, etc.).

Regras comerciais - lógica customizada para executar processos comerciais utilizando constantes comerciais com verificações aplicadas contra dados comerciais a partir das fontes de dados de empresa.

Constantes comerciais - uma variável configurável por usuário para uso durante todas as aplicações de cliente, e regras comerciais do lado do servidor e cliente (por exemplo, Regras, comerciais, Mensagens de alerta, e similares).

Conectores de fonte de dados - conectores de fontes de dados proj etados para fornecer continuamente acesso a uma ampla variedade de fontes de dados de empresa (por exemplo, bancos de dados como aqueles formatados de acordo com Oracle e Servidor SQL, sistemas de envio de mensagem como Série MQ ou MSMQ, aplicações CRM como Siebel ou Peoplesoft, serviços genéricos de rede, e assim por diante.).

Processo comercial - metáforas, como um processo de "Fluxo de força" da Dexterra, IN.c, de Bothell, Washington, E.U.A., que define um paradigma de navegação de formulário para formulário para modelagem de processos comerciais.

Formulários - uma combinação de telas de display visual padrão (por exemplo, Visualizar, Editar, Localizar, e similares) com lógica acionada por evento que são projetadas para mostrar informações, coletar informações, e orientar o usuário através de um processo comercial dado,mencionado aqui como um "Fluxo de força" ou um "Fluxo de campo."

Visualizações - uma representação modificada dos dados identificados a partir de uma fonte de dados de empresa ou aplicação que são utilizados por um ou mais Objetos comerciais.

Filtros - Um filtro que pode ser aplicado a uma Visualização para modificar os dados disponíveis para um Objeto comercial.

Esses componentes podem ser utilizados para especificar a configuração (arquitetura lógica) de qualquer aplicação de cliente que é construída utilizando uma estrutura de tecnologia como a ".NET" da Microsoft Corporation e ferramentas como "Visual Studio.net" da Microsoft Corporation. Aqueles versados na técnica estarão familiarizados com tais ferramentas de programação para especificar uma aplicação e seus obj etos de dados associados.

A Plataforma de Empresa móvel ilustrada na figura 1 é implementada como uma estrutura acionada por metadados. A estrutura prove serviços de rede de servidor e cliente integrados, permitindo a conexão, configuração e serviços de gerenciamento de dados necessários para usar soluções de empresa móveis de missão crítica, à prova de falha.

A figura 2 ilustra que, na plataforma de empresa móvel da figura 1, a estrutura de tabelas de banco de dados relacionais e obj etos comerciais de aplicação externa são mapeados para visualizações como metadados. Uma ou mais visualizações são consumidas por Obj etos comerciais, também definidos em metadados, que são por sua vez utilizados pela aplicação móvel. A aplicação móvel utiliza uma estrutura de cliente, mencionada como o "Dexterra Smartclient", que gerencia a instanciação dos Objetos comerciais, Acesso deDados Locais ao banco de dados fisíco, subjacente que reside no dispositivo de cliente móvel, integração de Dispositivo, bem como a comunicação de dados de servidor-cliente através dos serviços de gerenciador de dados e/ou rede de conector. Na plataforma, especificações para todas as camadas lógicas (por exemplo, Objetos comerciais, Visualizações, filtros e Conectores) são definidas e mantidas nos metadados.

A plataforma de empresa móvel é arquitetada como uma pilha lógica, projetada para isolar camadas na arquitetura lógica a partir de todos exceto membros não adjacentes. Na parte inferior da pilha lógica, camada Alvo, estão dados que residem nas fontes de dados de empresa, back-end. A plataforma trabalha com os dados de fonte no lugar, e não requer que informações no sistema de registro de back-end sej am replicadas para um banco de dados de replicação de nivel médio. Isso é, não necessário armazenamento de dados interino. Isto prove flexibilidade em desenho, bem como acesso de dados em tempo real e pode ajudar a reduzir o custo total de propriedade da plataforma e aplicações, e auxilia a simplificação dos processos de gerenciamento de dados.

A próxima camada para cima na pilha lógica é a camada de Conector. A camada de Conector prove uma construção programática que descreve a armazenamento de dados de back-end para o servidor de aplicação em um formato relacionai. As informações referentes a como se conectar a uma fonte de dados de empresa, bem como aos ajustes de segurança (como métodos de autenticação e definições de grupo e usuário) são armazenadas nos metadados, e são mantidas utilizando o componente de Administrador.A camada seguinte na pilha é a camada de Visualização, que compreende obj etos que fornecem um mapeamento de um para um para um objeto ou tabela em uma fonte de dados de empresa, de back-end. Por exemplo, se um sistema de back-end tiver uma tabela denominada CUST__ADDR (endereço de cliente), e dados a partir daquela tabela forem necessários para uso em uma aplicação, então uma Visualização será criada no componente de Administrador. A Visualização de Administrador poderia ser denominada, por exemplo, CUSTOMER_ADDRESS, para representar aqueles dados no ambiente da plataforma de empresa móvel, fora das fontes de dados de empresa. Deve ser entendido que uma

Visualização tem propriedades que correspondem às propriedades ou colunas do objeto de dados no sistema de back-end- Entretanto, não é necessário que todas as propriedades na fonte de dados de back end sejam exigidas como propriedades na Visualização. Realmente, as propriedades exigidas são definidas no componente administrativo e armazenadas como metadados no exemplo fornecido há pouco, as propriedades poderiam incluir campos como ID, STREET__ADDR, CIDADE, ESTADO, E ZIP_CODE.

Adicionalmente, o usuário pode definir os tipos de dados das propriedades na Visualização, e esses tipos de dados podem ser independentes dos tipos de dados das propriedades correspondentes na fonte de dados de empresa. Outras opções das propriedades de visualização que podem ser identificadas são identificador' exclusivo, leitura somente, indexação, propriedade exigida e comprimento. Todas as informações acima são armazenadas como metadados.

A camada de Visualização também prove uma indicação de conflitos de dados, e prove um meio para resolver tais conflitos. Conflitos de dados podem ocorrer, por exemplo, sempre que houver alterações de dados entre oque está sendo uploaded a partir do cliente móvel e o que existe no servidor. A resolução de tais conflitos pode ser executada na camada de Visualização, executando regras comerciais como permitir que a alteração de dados mais recentes sempre tenha precedência, ou permitir que alterações de dados de uma fonte especifica (por exemplo, o cliente móvel ou uma fonte de dados de empresa) tenham precedência dependendo do tipo de dados (por exemplo, dados de campo ou dados de conta de cliente) . Isso é descrito adicionalmente abaixo, em combinação com o Serviço de Rede de Gerenciador de dados.

Como ilustrado na figura 2, as Visualizações podem ser definidas contra múltiplos objetos em múltiplos armazenamentos de dados, desse modo fornecendo flexibilidade em uso de aplicação e no uso de sistemas no lugar, sem a carga de replicação de dados. Como com os Conectores, as definições de Visualizações são armazenadas em metadados, e são gerenciados com o Administrador. Aqueles versados na técnica entenderão detalhes de definições de dados em metadados, sem explicação adicional. Como observado acima, Filtros podem ser aplicados às Visualizações, para modificar os dados que são passados para a camada seguinte. O Administrador prove recursos de gerenciamento de Visualização, incluindo um *Mágico" de Visualizações que automaticamente cria Visualizações com base na interface de obj eto ou definição de tabela dos objetos de armazenamento de dados de back-end (a partir das fontes de dados de empresa).

A próxima camada para cima no diagrama da figura 2 inclui os Obj etos Comerciais, que são mapeados ou associados a uma ou mais Visualizações. Um Obj eto comercial da plataforma é a entidade programática com a qual um desenvolvedor fará interface ao construiraplicações móveis de customização. Os Objetos comerciais incluem múltiplas propriedades, cada um dos quais pode ser de um tipo de dados simples, ou pode ser outro Objeto comercial- Como os Objetos comerciais da plataforma podem ser mapeados para múltiplas Visualizações, os desenvolvedores podem trabalhar com uma única entidade que representa dados fornecidos de múltiplas fontes de dados homogêneos. Desse modo, um único Objeto Comercial definido de acordo com a plataforma de empresa móvel da invenção pode incluir dados de múltiplas fontes de dados de empresa potencialmente incompatíveis, como de diferentes formatos de propriedade.

Ao criar ou modificar aplicações para as aplicações móveis e dispositivos de clientes móveis, os desenvolvedores podem interagir exclusivamente com a camada de Obj eto comercial. Isso isola os, desenvolvedores de qualquer exigência para entender ou interagir diretamente com os sistemas de back-end (fontes de dados de empresa) para os dados de fonte. Desse modo, a camada de Obj eto comercial prove uma interface baseada em obj eto para desenvolvedores de aplicação, extraindo os detalhes de persistência e recuperação de dados. Não há necessidade do desenvolvedor interagir diretamente com o armazenamento de dados local no dispositivo móvel. Além disso, devido à natureza de dados desconectados, o cliente móvel, através da interface de Obj eto Comercial, gerencia automaticamente o processamento de alterações de dados, pela armazenagem de alterações de dados localmente no cliente que serão passadas para o servidor de aplicação durante um processo de atualização. Isso isola adicionalmente os

desenvolvedores dessa tarefa de programação de rotina.

Os Obj etos Comerciais existem no dispositivo de cliente móvel como metadados, e são também gerenciadosutilizando o Administrador (figura 1). O uso de metadados em toda a plataforma de empresa móvel prove um ambiente no qual os atributos e comportamento da maioria das entidades de dados podem ser configurados através de uma interface de usuário gráfico em vez de codificado.

A natureza acionada por metadados da plataforma de empresa móvel permite a execução de processos comerciais no cliente móvel através de uma arquitetura de servidor sem estado. Através dos metadados, a aplicação móvel pode ser configurada e customizada. Os metadados definem a

estrutura dos objetos comerciais referenciando os dados de empresa comerciais ao dispositivo móvel e define os eventos que acionam regras comerciais que regem os processos comerciais.

O banco de dados de metadados contém a referência das informações comerciais de back-end de aplicação cruzada, funcional-cruzada que é exposta através dos Conectores para configurar um obj eto comercial. Esse processo é realizado através do componente de Estúdio (figura 1) para configurar e referenciar as informações comerciais de fonte de dados de empresa de conexão com os Objetos comerciais. Isso prove o percurso para os dados específicos para as aplicações móveis, assegurando que nenhum dado comercial de uma fonte de dados de empresa seja armazenada em seu formato nativo de dados no servidor de aplicação ou em qualquer outro armazenamento de dados interino do sistema para atualizações de dados. Essa abordagem não invasiva e sincrona em tempo real utilizando os metadados permite que a plataforma de empresa móvel se conecte de forma eficaz com sistemas de back-end com uma quantidade minima de ruptura enquanto maximiza acesso de dados funcional-cruzado, consistência de dados e integridade de dados.IV. COMPONENTES DE PLATAFORMA DE EMPRESA MÓVEL A. APLICAÇÕES MÓVEIS

Como observado acima, o cliente móvel 102 (figura 1) pode incluir aplicações instaladas 12 4 que implementam processos comerciais da empresa. A aplicação pode

alavancar a plataforma de empresa móvel descrita acima, e demonstra como a aplicação instância os objetos comerciais que acionam o processo comercial configurado em metadados.

Por exemplo, informações de Pedido de Trabalho ou Tarefa seriam fornecidas para a aplicação móvel através de visualizações e seriam acessadas através de um obj eto comercial. Na recuperação dos dados comerciais através da definição de visualização, utilizando o serviço de rede de gerenciador de dados, o obj eto comercial pode fornecer os dados comerciais à aplicação móvel para descrever as tarefas. Esses dados são armazenados em um banco de dados relacionai locais no dispositivo móvel. Quando uma

atualização para os dados de tarefa é comprometida com o obj eto comercial de tarefa em uma solicitação a partir do pedido, a aplicação de Smartclient persistirá as alterações no armazenamento de dados definido por visualização no cliente móvel, então o Smartclient gerencia as atualizações de dados de volta para a fonte original de dados através do serviço de rede de gerenciador de dados, assegurando integridade e consistência de dados.

Pela utilização da profundidade, amplitude, e potência de serviços de rede (por exemplo, conexão, configuração, e serviços de gerenciador de dados) que são disponíveis na plataforma de empresa móvel descrita aqui, um grande conjunto de aplicações móveis pode ser facilmente construído, incluindo aplicações como produtividade de força de vendas, serviço de clientes, e soluções de suporte. Tais aplicações podem ser integradas com um amploconjunto de aplicações verticais incluindo soluções de indústria de óleo/gás, cuidados com a saúde/medica e de serviço financeiro.

B. COMPONENTES DO SERVIDOR

O servidor de aplicação é um tipo de aplicação de plataforma acionada por metadados e prove informações, aplicações, e processos comerciais para o cliente móvel, e assegura integridade de dados gerenciados entre a plataforma de empresa móvel e um hospedeiro de fontes de dados de empresa de back-end. O servidor de aplicação é uma solução de alto desempenho, baseado em processo construído na tecnologia ".NET" da Microsoft Corporation de Redmond, Washington, E.U.A. Utilizando a tecnologia X\NET", a solução de empresa móvel é uma estrutura que é nativa de Serviços de Rede através do uso de XML e SOAP para troca de dados e transporte. O servidor de aplicação prove três Serviços de Rede de núcleo, como mostrado no diagrama de arquitetura funcional da figura 1:

Serviço de rede de conector

O Serviço de rede de Conector fornece integração não invasiva da infra-estrutura existente de aplicações de empresa enquanto mantém controle das Condições de Integridade de dados entre os clientes móveis e as fontes distintas de dados de empresa.

Serviço de rede de configuração

O Serviço de Rede de Configuração gerencia os metadados definindo os dados comerciais, obj etos comerciais, regras comerciais, constantes comerciais e configuração de sistema como autenticação, registro, segurança e papéis que abrangem as aplicações móveis que são passadas para o cliente móvel - a aplicação de componente que é residente no dispositivo móvel.

Serviço de Rede de Gerenciador de dadosO Serviço de Rede de Gerenciador de dados orquestra as interações de atualização entre a aplicação de cliente móvel, o servidor de aplicação, e as fontes de dados de empresa de terceiros. Adicionalmente, o Serviço de Rede de Gerenciador de dados prove a capacidade de comunicar-se diretamente com a camada de conector para consultas em tempo real. O Serviço de Rede de Gerenciador de dados fornece flexibilidade no modo que gerencia as várias condições referentes a múltiplas atualizações por múltiplos usuários para as múltiplas fontes de dados de empresa para executar a integridade dos dados. O Serviço de Rede de Gerenciador de Dados pode fazer isso através do servidor de aplicação ou orientar para qualquer API e/ou Serviço de Rede publicado por terceiros -

Desse modo, o Serviço de Rede de Gerenciador de Dados pode gerenciar uso de atualizações de aplicação e alterações de dados por todos os clientes móveis do sistema.

Cada um desses componentes será descrito a seguir em maior detalhe.

1. Serviço de Rede de conector

O Serviço de Rede de Conector é projetado para suportar comunicação com qualquer fonte de dados em conformidade com ODBC ou API de Serviço de Rede. O Serviço de rede de Conector permite que um cliente defina e construa visualizações com base em dados armazenados em um ou mais sistemas terceiros. O Serviço de Rede de Conector tem uma interface publicada que permite atualizações a granel padrão bem como acesso de dados em tempo real a partir de um cliente móvel.

O Serviço de Rede de conector prove a conexão de camada fisica entre a meta-aplicação de servidor de aplicação e a interface especifica das fontes de dados deempresa. Os conectores suportam serviços de notificação e gerenciamento de disputa de banco de dados, gerenciamento de transação, e manipulação de erros. Em uma configuração de cliente default, o sistema de plataforma de empresa móvel é usado para clientes com um ODBC ou conector de Serviço de rede. Aqueles versados na técnica serão capazes de produzir conectores para os sistemas de empresa mais comuns, como Siebel, SAP, PeopleSoft, Oracle, SQL Server, e similares.

Por exemplo, um conector de aplicações "Oracle" permite que um cliente faça chamadas para serviços de suporte Oracle, através das construções de dados mais próximas que o cliente tem com APIs (como procedimentos PL/SQL) ou diretamente com o próprio banco de dados de empresa através de ODBC. Como com todos os conectores de ODBC a interrogação dinâmica dos esquemas de RDBMS é automaticamente executada, expondo o desenho fisico especifico do banco de dados. Isso fornece ao cliente uma visualização hierárquica das interfaces efetivas naquele sistema.

A figura 3 mostra um exemplo de como os Conectores fazem interface das fontes de dados de empresa com a plataforma de empresa móvel. NO lado esquerdo da figura 3 estão representações de múltiplas fontes de dados de empresa, incluindo uma fonte de dados ERP 302, uma fonte de dados CRM 304, uma fonte de dados -de Finanças/HR 306, uma fonte de dados de ODBC/Legado 308, e podem incluir outros Serviços de Rede ou outras fontes (não mostradas). Na porção média da figura 3 está uma representação dos metadados 312 que especifica para o servidor de aplicação 314 como os dados de diferentes fontes de dados de empresa serão armazenados e relacionados no cliente móvel 316, que é representado no lado direito da figura 3.Desse modo, nesse exemplo, dados identificados como 0RDER_ID existem na fonte de dados de ERP. Os dados identificados como FJMAME e L_NAME existem na fonte de dados CRM. Os dados identificados como CRED__LIM existem na fonte de dados de Finanças/HR, e dados identificados como WARRANTY são armazenados na fonte de dados ODBC/Legado. Todos esses dados identificados são armazenados nas fontes de dados de empresa, como nos sistemas de back-end office.

Nos metadados 312, a definição de dados a partir das fontes de dados de empresa é mapeada para visualizações que são utilizadas para criar o armazenamento de dados no cliente e armazenam os dados comerciais relevantes no cliente móvel a partir das fontes de dãdõs de empresa em um banco de dados relacionai. O acesso a esses dados comerciais é executado através da camada de obj eto comercial definida e armazenada em metadados no cliente móvel. Como mostrado na figura 3, o ORDER_ID da fonte de dados ERP é mapeado para uma propriedade de objeto comercial denominada OrderlD, cu j a definição relacionai é armazenada em metadados 318 no cliente móvel 316 e utilizada por uma ou mais das aplicações móveis também definidas em metadados. Os dados F_NAME a partir da fonte de dados de empresa CRM são mapeados para (armazenados na) definição de propriedade de objeto comercial FirstName armazenada no banco de dados de cliente móvel, e os dados L_NAME são mapeados para a propriedade de obj eto comercial LastName. Similarmente, os dados CRED_LIM a partir da fonte de dados de Finanças/HR são mapeados para a propriedade de objeto comercial CreditLimit, e os dados WARRANTY a partir da fonte de dados ODBC/Legado são mapeados para a propriedade de objeto comercial de Garantia. Desse modo, dados a partir de fontes de dados de empresa potencialmente diferentes e incompatíveisdiferentes 302, 304, 30 6, 308, 310 são fornecidos ao cliente móvel através dos Serviços de Rede Gerenciador de Dados para o armazenamento de dados local (representado pelas linhas a partir das fontes de dados de empresa para o servidor de aplicação 314) no formato adequado para acesso utilizando um dos objetos comerciais no cliente móvel (indicado no cliente móvel 316 com valores efetivos). Tipos de conector

Os conectores que são suportados pelo Serviço de Rede de Conector incluem os três tipos de conector a seguir:

1. O Conector de Serviços de rede é utilizado quando a plataforma móvel está conectando com um sistema de terceiro (a) que não está em conformidade com ODBC, ou (b) não permite conectividade ODBC/RDBMS, ou (c) cuja interface é definida por um API padrão e pode ser envolvida e definida por Linguagem de Descritor de Serviço da Rede (WSDL).

2. O conector ODBC/RDBMS é utilizado quando conectando a plataforma móvel a um sistema terceiro (a) que está em conformidade com ODBC e (b) permite acesso direto a ODBC/RDBMS e (c) cujos dados são localizados fisicamente no mesmo ambiente LAN ou acessíveis através de um protocolo de comunicação de suporte do transporte (como RPC, TCP, etc).

3. O conector API é similar ao Conector de Serviços de rede porém (a) requer que o API seja acessível através de protocolos não de Internet como RPC e 9b) é utilizado se a Interface de Serviços de rede não estiver disponível.

A leitura de esquemas, através de conector ODBC/RDBMS, informações é realizada através do uso da porção de Estúdio 130 (figura 1) da plataforma de empresa móvel, utilizando a aplicação de Administrador. A porçãode Estúdio é utilizada para configurar o mapeamento de definição de Visualização para a fonte de dados de back-end e mapear a definição de uma ou mais Visualizações para um ou mais Objetos comerciais. Ao definir a definição de Visualização ou mapeamento das Visualizações para Objetos comerciais, utilizando o administrador, as informações são armazenadas como metadados. Durante um processo de

atualização com o servidor de aplicação e fonte de dados de empresa, os metadados são lidos para determinar como ler, persistir e remover os dados

(seiecionar/inserir/atualizar/deletar funções) enquanto gerencia e executa a integridade de dados utilizando tais funções como detecção/resolução de conflitos, transações tanto inerentes e compensando onde apropriado.

Utilizando o conector ODBC/RDBMS, os dados são lidos, persistidos e/ou removidos através de afirmações ANSI SQL e/ou procedimentos armazenados no caso de RDBMS de Oracle ou SQL Server da Microsoft Corporation (81, 91, etc.) . Utilizando o conector de Serviços de Rede/API, dados são lidos, persistidos e/ou removidos chamando a função API apropriada ou método para a transação.

2. Serviço de rede de configuração

O Serviço de Rede de configuração consumido pela Dexterra Studio prove um modo inter-operável fácil para administradores, analistas comerciais e desenvolvedores para implementar, configurar e administrar a solução de Empresa Móvel da Dexterra. O Serviço de rede de

Configuração permite fácil manipulação dos metadados utilizados para configurar e customizar os dados e definições de processo de aplicações Móveis. Esse serviço será mais bem entendido com referência às características do componente de Administrador, que é descrito em maior detalhe abaixo.3. Serviço de rede de gerenciador de dados Modelo de processo de atualização

Um modelo de processo de atualização é utilizado no sistema, no qual aplicações móveis atualizam seus dados retidos de forma local (a aplicação ou seus objetos comerciais) com o banco de dados de empresa de back-end utilizando um conjunto de componentes Net de núcleo que são expostos como Serviços de rede para fácil interoperabilidade.

O Serviço de Rede de Gerenciador de dados atualiza a aplicação móvel e todos os seus dados definidos por objetos comerciais associados. O modelo de processo de Atualização permite transferência de dados dúplex entre as fontes de dados de empresa através do servidor de aplicação Dexterra e o cliente móvel, permitindo que atualizações sejam feitas enquanto o cliente móvel está conectado à rede, fundindo as atualizações entre clientes quando estão conectados. Quando no estado desconectado, as atualizações são fundidas no ambiente do cliente, até um momento em que um estado conectado seja obtido e a solicitação de atualização possa ser iniciada.

O modelo de processo de atualização assume a abordagem "tudo ou nada". Se uma falha ocorrer antes que o fluxo inteiro seja transferido do servidor de aplicação para sobre o cliente móvel (ou antes que o fluxo inteiro seja uploaded do cliente para o servidor), então o Serviço de Rede de Gerenciador de dados no servidor de aplicação não recebe uma confirmação sobre a transação de download (ou upload). Como resultado, o servidor carrega a

inteligência para gerenciar o estado de cliente com relação a se requer uma reversão de dados ou simplesmente uma nova tentativa. Quando o cliente móvel executa uma operação de processo de atualização a segunda vez, o servidor deaplicação leva em consideração o estado original deinformação e pode fornecer os resultados se o servidor deaplicação tiver processador ou processar novamente no casode todas as informações exigidas nunca terem sido recebidaspelo servidor de aplicação desse modo executando a entregaconfiável de informações somente uma vez entre o clientemóvel e servidor de aplicação. Isso, no caso, executa aintegridade dos dados à medida que se movem do clientemóvel para uma ou mais fontes de dados de back end.Quebra do processo de atualização

Dois tipos de processamento' de atualização sãosuportados:

1: obter o mais recente: nesse tipo deatualização, o cliente móvel faz uma solicitação para obteras informações mais recentes a partir das fontes de dadosde empresa através do servidor de aplicação Dexterra. 0servidor de aplicação Dexterra processa a solicitação erecupera as informações comerciais a partir das múltiplasfontes de dados utilizando o Serviço de Rede de ConectorDexterra e entrega as informações comerciais para o clientemóvel.

2: atualizar (atualização dúplex): nesse tipo deatualização, registros tanto na extremidade do cliente comodo servidor são intercambiados executando a integridade dosdados tanto no cliente móvel como nas fontes de dados deempresa de back end utilizando parâmetros configurados deResolução de Conflito Dexterra.

Detecção/resolução de conflitos

A resolução de conflitos descreve as regrasutilizadas para arbitrar sobre conflitos de dados causadospor alterações feitas entre um cliente móvel e uma ou maisfontes de dados de empresa de back end. Isso é executadopela identificação do conflito (Detecção) e então resolução(Resolução) do conflito em um ou mais vários modos.

O servidor de aplicação Dexterra pode detectarconflitos em um de três modos: Revisão, Selo dedata/horário ou Manual bem como identificar uma situação deconflito por nivel de linha ou coluna.

A revisão é um ajuste onde um campo especifico oupropriedade é identificado em uma única fonte de registrocomo revisado e o servidor de aplicação Dexterra utilizaráisso para determinar se os dados foram alterados na fontede dados de back end ou cliente móvel.

Selo de data/horário

O selo de data /horário é um a j uste onde um campoespecifico ou propriedade é identificado em uma única fontede registro como selo de data/horário e atualizado apósqualquer inserção/atualização ou ação de deietar e oServidor de aplicação Dexterra utilizará isso paradeterminar se os dados foram alterados na fonte de dadosback end ou cliente móvel.

Manual é um ajuste onde não há campo especificoou propriedade para identificar uma situação de conflito emuma única fonte de registro, portanto, o Servidor deaplicação Dexterra compara todos os dados de propriedade oucampo para definir exclusividade e detectar se os dadosforam alterados na fonte de dados de back end ou clientemóvel.

Dependendo da configuração do Servidor deaplicação Dexterra, Conflitos são resolvidos em um dequatro modos: Primeira Atualização vence, Últimaatualização vence, Resolução de admin. Ou Regra do lado doservidor

Primeira atualização venceSob o modelo de Primeira atualização o servidorde aplicação somente aceitará alterações de qualquerregistro que seja o primeiro a fazer uma atualização. Seum registro for primeiramente atualizado pela fonte dedados de back end e um conflito for detectado pelo Serviçode Rede de Atualização, em vez de retornar um erro, oServiço de Rede de Gerenciador de dados abandonará a versãofornecida pelo cliente e retornará uma cópia da versão maisrecente do registro a partir da fonte de dados de empresade back end para o cliente móvel.

Última atualização vence

Sob o modelo de Última atualização vence, oservidor não necessita detectar conflitos. Em vez disso,simplesmente persistem as alterações a partir do clientemóvel para a fonte de dados de empresa de back endsobrepondo o registro atual na fonte de dados de empresa deback end.

Resolução de admin. (ou manual)

Quando configurado para resolução Manual/admin.,o servidor tratará todos os conflitos como exigindointervenção manual para resolver e retornará uma cópia doregistro atual a partir da fonte de dados de empresa deback e opcionalmente notificará através de qualquer serviçode notificação (SMS, E-mail, etc.) que uma situação deconflito surgiu e permitirá resolução através doAdministrador Dexterra. Ao fazer isso permite resolução deconflito a nível de coluna uma vez que o Administradordetermina os valores a reaplicar de volta à fonte de dadosde empresa de back end, seletivamente.

Regras do lado do servidor

Regras do Lado do Servidor customi záveis podemser criadas para determinar de forma mais programática eespecífica como certas situações de conflito devem serresolvidas. Por exemplo, um conflito pode ser resolvidocom base nos valores de dados em um registro. Essaflexibilidade permite controle total sobre as açõesespecificas circundando um cenário de resolução deconflito.

Uso do cliente a partir do servidor

0 servidor de aplicação contém a definição de uma.ou mais aplicações de campo móveis que devem sertransferidas para o cliente móvel, incluindo osFormulários/telas representados como tarefas (mencionadoscomo "FormFlows"), interações de dados (mencionados como"FieldFlow") , e grupos de FormFlows e FieldFlowsconstruídos em um Fluxo de trabalho/Processo Comercial(denominado "ForceFlow"). Os FormFlows, FieldFlows eForceFlows são descritos adicionalmente abaixo. Adefinição de aplicação também inclui os metadadosconfigurados associados a uma aplicação como Visualização,Objeto comercial, definição de Constantes comerciais. Sãotambém incluídos no uso os dados comerciais específicos apartir de uma ou mais fontes de dados de empresa de backend necessárias para rodar o cliente móvel em um estado"ocasionalmente" conectado.

0 servidor de aplicação prove a fundação na qualfornecer e gerenciar aplicações e conectar-se a sistemas efontes de dados de empresa existentes. As aplicações deplataforma de empresa móveis são distribuídas e gerenciadaspara os dispositivos móveis, como dispositivos Pocket PC eTablet PC, pelo servidor de aplicação, fornecendo umaadministração altamente gerenciavel de todas as interfacesde usuário no campo.

C. COMPONENTE DE ADMINISTRADOR

Como observado acima, o componente deAdministrador (figura 1) permite que os administradores desistema executem alterações que são relativamente regularesou freqüentes. 0 componente de Administrador prove acessoa variáveis de decisão, conteúdo de lista suspensa, eoutras informações em um formato apropriado paragerenciamento por analistas comerciais ou administradores.Essa abordagem à administração permite que osadministradores de sistema estendam muitas funções parabaixo ao nivel do Administrador sem comprometer aintegridade do sistema.

Por exemplo, dados compreendendo informaçõescomerciais que são utilizadas para definir os processoscomerciais da empresa podem ser recebidos através de umformulário de definição de Objetos comerciais- O Serviçode rede de Configuração prove acesso a esse aspecto docomponente de Administrador.

D. COMPONENTE DE CLIENTE

Como observado acima, o cliente 102 (figura 1) naarquitetura de plataforma de empresa prove uma estrutura naqual a aplicação móvel permite o uso de processoscomerciais baseados em papel utilizando técnicasmencionadas como "ForceFlow", "FieldFlow" e "FormFlow", eutilizando Serviços de rede, desse modo permitindocomunicações entre o cliente móvel' e o Servidor deaplicação Dexterra e as fontes de dados de empresa atravésde uma rede LAN/WAN, como a Internet, via conexões ligadaspor fio e sem fio, A aplicação móvel que roda nosdispositivos de cliente funciona em um modo que é otimizadopara dispositivos de fator de formulário pequenos quefornecem uma exceção, experiência fácil de aprender pelousuário.

No sistema ilustrado, o cliente é uma estruturade objeto que é construída utilizando o XX.NET CompactFramework" da Microsoft Corporation que é ciente demetadados. O componente de cliente permite fornecimento defuncionalidade de aplicação de classe de empresa nosdispositivos móveis, que preferivelmente operam de acordocom o sistema operacional "PocketPC" ou sistema de operaçãoMicrosoft Tablet PC a partir da Microsoft Corporation. Ocomponente de cliente também integra com funcionalidade"PocketPC" existente para fornecer integração continua comfuncionalidade de tela de Calendário, Tarefa e Hoje dainterface de PocketPC. Prove desse modo um ambienteestável, eficaz no qual trabalhar.

FormFlows, FieldFlows, ForceFlows

Quaisquer tarefas ou operações de processocomercial na forma de telas de display são denominadas"FormFlows"; Os FormFlows são utilizados para iniciarinterações de processo denominadas "FieldFlows" quepermitem a iniciação de processos comerciais, os quais sãomencionados como "ForceFlows". Os FieldFlows permitemlançamento de ForceFlows "fora de banda" para trazerelasticidade de mundo real para os processos comerciais.

Os FormFlows são divididos em três categorias:(1) informação; (2) Atividade; e (3) Atualização. UmFormFlow de Informação é uma tela que mostra informaçõesnecessárias por um usuário móvel para preencher a tarefalógica seguinte no processo comercial. Um FormFlow deAtividade é uma tela que mostra algo que o usuário podenecessitar fazer ou executar. Um FormFlow de Atualização éuma tela que é exibida quando um usuário móvel é prompted aentrar dados que serão retornados às aplicações dehospedeiro (as fontes de dados de empresa).

Um FieldFlow pode ser necessário, por exemplo,quando uma parte poderia ter falhado e uma busca de bancosde dados de inventário poderia necessitar ser executadapara ver se quaisquer partes casadas ou problemas similarescom soluções existem e são disponíveis, denominado umaconsulta, ou um FieldFlow pode ser necessário quando umaparte poderia necessita ser ordenada ou atribuída ouprogramada para fornecimento ao cliente, um FieldFlowdenominado uma atualização.

Um ForceFlow é um processo comercial, e portantoé uma coleção de FormFlows e FieldFlows. Um exemplo de umaForceFlow seria registro de tempo, viagem, e despesa que éassociado a um evento de despacho ou trabalho.

Com referência novamente à figura 2, essediagrama de blocos mostra como as relações entre colunas ecampos na aplicação alvo são relacionadas a informações no"FormFlows'7 (etapas no processo comercial representadascomo "Formulários" na aplicação) e são então associadas noForceFlow (o processo comercial). Pode haver muitosObjetos comerciais em um FormFlow e potencialmente mais doque um FormFlow em qualquer processo comercial.

Filtros permitem que características e condiçõessej am colocadas sobre os dados quando referenciados naaplicação móvel. Por exemplo, tipo de dados (por exemplo,Data), tipos válidos (por exemplo, somente Segunda-feiraaté Sexta-feira), e quaisquer condições de conflito podemser detectadas. Outras características e condições defiltro podem ser configuradas.

Visualizações definem o local de armazenagem edados para uso em um ou mais Objetos comerciais, e o Objetocomercial pode ser baseado em uma ou mais Visualizações.Isso permite que características adicionais sejamassociadas. Por exemplo, um Objeto Comercial pode sermencionado como "Cliente", que pode incluir detalhes decliente padrão; localização, contatos, inventário, e tambémSLA e outros atributos que a aplicação gostaria declassificar como Cliente porém não retidas na mesma tabelaAlvo ou mesmo aplicação Alvo.

V. ARQUITETURA DE ADAPTADOR

A arquitetura de adaptador, de acordo com apresente invenção, é ilustrada na figura 4. Alguns doscomponentes ilustrados na figura 4 são análogos acomponentes ilustrados na figura 1. Os componentes nafigura 4 que executam funções para as quais um componentecorrespondente é fornecido no sistema da figura 1 serãoidentificados na figura 4 com o mesmo numerai dereferência, exceto por começar com "4" em vez de "1".

A figura 4 é um diagrama de blocos de um ambientedo sistema de computador apropriado, 400, construído deacordo com a presente invenção. A figura 4 mostra umdispositivo de cliente móvel 4 02, como um dispositivo deAssistente Pessoal digital (PDA) que opera em combinaçãocom os sistemas operacionais Microsoft Pocket PC ou PalmPDA. O dispositivo de cliente 402 inclui os mesmoscomponentes, como descrito com relação ao dispositivo decliente 102 da figura 1, porém não são ilustrados na figura4 para simplicidade de ilustração. 0 dispositivo de clientemóvel 402 comunica-se através de uma conexão de rede 404com um servidor de aplicação 406 para solicitar dados apartir do servidor e receber atualizações de dados,fornecer novos dados, e receber alterações de configuração.Deve ser entendido que múltiplos clientes móveis 4 02 podemse comunicar com o servidor 40 6. Somente um únicodispositivo de cliente 402 é mostrado na figura 4 para finsde simplicidade.

Os clientes móveis 4 02 consomem os serviços derede de conector do lado do servidor para recuperação dedados em tempo real a partir de múltiplos armazenamentos dedados de empresa. Adicionalmente, os clientes móveisconsomem os serviços de rede de gerenciador de dados dolado do servidor para o gerenciamento de atualizações dedados do lado do cliente em tempo real, atualizações dedados do lado de servidor e atualizações de configuração dosistema.

0 servidor de aplicação 406 comunica-se comfontes de dados de empresa 408, como fontes de dados CRM,fontes ERP, recursos de sistema financeiro, armazenamentosde dados de legado, e similares.

Um componente de uDexterra Studio" 430 comunica-se com o servidor 406 e inclui uma aplicação deadministrador e uma aplicação de desenvolvedor (nãoilustrado na figura 4), Mais particularmente, o componentede Estúdio faz interface com o Configurador do servidor4 06, e um DDS de servidor de Dados faz interface com oservidor e a Estrutura de Adaptador do servidor 406, que secomunica com as fontes de dados de empresa 408.

A Estrutura de Adaptador prove uma interface queexecutará entradas e saldas especificas necessárias nodeslocamento de dados entre o servidor 40 6 e qualquer outrafonte de dados de empresa. O Gerenciador de Dados doservidor 4 0 6 solicitará e responderá a qualquer componentede conector adequadamente definido para comunicar-se com asfontes de dados de empresa 408 através da Estrutura deAdaptador. Desse modo, o servidor 406 utiliza a definiçãodos Obj etos de Conexão, Obj etos de Comando, Obj etos deDados, e Visualizações para determinar como e quais dadosrecuperar ou persistir para uma fonte de dados de empresade back end.

Um kit de ferramenta de desenho ("DexterraAdapte r Designer", ou DAD) é fornecido com o Studio 4 30para permitir que os desenvolvedores especifiquem oscomponentes da Estrutura de Adaptador. Isto é, o DAD 4 30prove a um desenvolvedor o meio para conectar e construircomponentes de dados de Estrutura de Adaptador paraqualquer Adaptador suportado Dexterra utilizando o plug-inDexterra Studio VS.NET. Os componentes incluem Objetos deconexão, Obj etos de comando, Objetos de dados eVisualizações.

Utilizando o DAD 430, um desenvolvedor criará umObjeto de Conexão para uma fonte de dados de back endutilizando um Adaptador suportado Dexterra. Esse Objeto deConexão exporá (utilizando Descoberta/Intraspeção ouDescrição) o(s) objeto(s) de interface de dados disponíveisatravés do Adaptador como uma Tabela, Procedimentoarmazenado, Script ou Objeto (EAI, etc.). Utilizando oDesigner de Adaptador Dexterra, um desenvolvedor criaráentão uma série de Objetos de Comando que executam açõesespecificas através de um Adaptador como Selecionar,Inserir, Atualizar e/ou Deletar. Um desenvolvedor entãodefine um Objeto de Dados no qual eles selecionarão oComando de Selecionar, Comando de Inserir, Comando deAtualizar, e/ou Comando de Deletar, apropriado. UmaVisualização é então ligada ao Obj eto de dados para suasações de solicitar/responder. Utilizando essa ferramenta earquitetura, um desenvolvedor pode solicitar e persistirdados a partir de uma ou mais fontes de dados de empresa deback end mapeados em um único obj eto de dados definido noServidor Dexterra 4 06, desse modo fornecendo uma camada deabstração para as capacidades de interface e estrutura dedados fisica.

A. OBJETOS DE COMANDO

O Objeto de Comando da Estrutura de Adaptadordefine uma ação a ser executada através de um Adaptador(isto é, Conector) para recuperar ou persistir dados. Porexemplo, um comando MSaveCustomer" poderia ser definidopara salvar um objeto de dados de Cliente para uma fonte dedados de empresa através de um Adaptador. Os tipos ouformatos de Comando serão determinados pelos Adaptadores,de acordo com as fontes de dados de empresa, com as quaiseles fazem interface e portanto devem suportar. Por

exemplo, tipos de Comando em potencial para um sistema dedados móvel poderiam incluir Tabela, Procedimento, SQL,Script e Objeto.

Os Objetos de Comando especificarão uma ação queserá executada. De acordo com a invenção, os tipos de ação

de Comando incluem cinco ações definidas: (1) LER; (2)ADICIONAR, (3) ATUALIZAR, (4) REMOVER, e (5) LER paraEDITAR. Essas ações de Comando são descritas adicionalmenteabaixo em combinação com a discussão de Obj eto de Dados.

Objetos de Comando podem especificar filtros, que operarãoquando um Comando é executado. Cada filtro operará emdados de acordo com o tipo de dados de seu tipo de Comandocorrespondente. Um Comando incluirá um atributo de Coluna,que compreende as colunas de dados que são retornadasquando o Comando é executado. Por último, um Comando

inclui parâmetros que especificam valores necessários paraexecução adequada do Comando.

B. OBJETOS DE DADOS

O Obj eto de Dados associa Obj etos de comando pararecuperar ou persistir dados, logicamente agrupando osmesmos em um único obj eto (por exemplo, um obj eto deCliente) . Um Objeto de Dados é definido por (isto é, é oresultado de) Comandos que são executados nas fontes dedados de empresa, através dos Adaptadores. Como observadoacima, os Comandos incluem LER, ADICIONAR, ATUALIZAR,

REMOVER e LER para EDITAR. O Comando LER é um objeto decomando que recuperará dados, definirá quais colunas dedados são retornadas e quais são seus atributos, e anularáTipos de Dados para distribuição do Adaptador para oparadigma ".NET". O Comando ADICIONAR é um obj eto deComando que persistirá novas instâncias de dados através deum Adaptador para inserir novas instâncias de dados de volta na fonte de dados de empresa correspondente. O

Comando ATUALIZAR é um objeto de Comando que persistiráalterações em itens de dados existentes através de umAdaptador de volta para a fonte de dados de empresacorrespondente. O Comando REMOVER é um Objeto de Comandoque removerá dados de uma fonte de dados de empresa através

de um Adaptador, O Comando LER para EDITAR é um objeto deComando que recuperará um único registro com um RowLockatravés de um Adaptador.

Os Obj etos de Dados mapearao os elementos deretorno do Comando LER para os parâmetros dos Comandos

ADICIONAR, ATUALIZAR, REMOVER e LER para EDITAR. Um únicoObjeto de Dados pode recuperar e persistir dados através deComandos diferentes para Adaptadores potencialmentediferentes.

C. CONEXÕES.

Como anteriormente, as Conexões farão interfacecom as fontes de dados de empresa para fornecer acesso dedados pela aplicação de cliente móvel. Na Estrutura deAdaptador 430 descrita com relação à presente invenção, as

Conexões não se comunicarão diretamente com Visualizações,porém em vez disso farão interface diretamente com osObj etos Comuns, que eventualmente trocarão dados com osObjetos de Dados e Visualizações.

D. VISUALIZAÇÕES

Na Estrutura de Adaptador no Servidor 430 daconfiguração da figura 4, uma Visualização não é limitada auma única tabela de dados, como foi o caso na configuraçãoda figura 1. Em vez disso, uma Visualização é limitada aum Obj eto de Dados com Comandos definidos para LER,ADICIONAR, ATUALIZAR, REMOVER e LER para EDITAR. Dessemodo, uma interface de dados muito mais versátil éfornecida. A estrutura de uma Visualização é definidapelas colunas de dados selecionadas especificadas nocomando LER para o Obj eto de Dados. Além disso, filtrosnão são mais criados em um objeto de Visualização, porémsão criados em um Objeto de Comando.

Como descrito adicionalmente abaixo na próximaseção, os tipos de Visualização do sistema da figura 4incluem Visualizações diretas, Visualizações derivadas,Visualizações delegadas, e Visualizações de Definição. Aconfiguração dos Objetos de visualização no servidor 430permite abstração de operações CRU (Criar, Ler, Atualizar,Deletar) Visualizações para as fontes de dados de empresa,e permite que CRUD seja definida em vez de hard coded.

VI. TIPOS DE VISUALIZAÇÃO

Como observado acima, clientes móveis obtêmacesso a fontes de dados de empresa comercial através deVisualizações configuráveis que fazem interface com asfontes de dados através de Obj etos de Dados que sãodefinidos pelos Comandos, os quais por sua vez se comunicamcom as fontes de dados através de Conectores (tambémmencionados como Adaptadores). Cada tipo de Visualizaçãofará interface com as fontes de dados com umafuncionalidade diferente de modo que links de comunicaçõese outros recursos de sistema possam ser utilizados maiseficientemente.

No sistema ilustrado na figura 4, os tipos deVisualização incluem Visualizações diretas, Visualizaçõesderivadas, Visualizações delegadas, e Visualizações deDefinição. Como descrito adicionalmente abaixo, essesnovos tipos de Visualização fornecem maior controle sobreinterfaces de dados e podem ser configurados para maiorutilização de recursos de sistema.

A. VISUALIZAÇÕES DIRETAS

Uma Visualização Direta recuperará dadosdiretamente de uma fonte de dados de empresa através dosObjetos de Dados, Comandos e Adaptadores. Uma Visualizaçãodireta é um tipo de Visualização que é definida para ocliente móvel somente. A maioria dos tipos de Visualizaçãorecupera seus dados solicitados recorrendo a umarmazenamento de dados relacionais de cliente, local(cache) denominado SQLCE. Ao contrário, o tipo deVisualização Direta solicita dados diretamente das fontesde dados de empresa em vez de ir ao cache de armazenamentode dados de cliente local. No evento de uma conexão falhacom as fontes de dados de empresa, o sistema da figura 4prove uma operação FailOver opcional que pode recuperardados do SQLCE se as fontes de dados de empresa nãoestiverem disponíveis. Isso permite que uma operaçãosemelhante a Servidor/Cliente de uma Aplicação móvel onde ocontrole sobre quais dados são persistidos localmente, emcomparação com quais dados são necessários em tempo real(como dados de inventário), possa ser configurada -

Quando a aplicação móvel para o sistema (figura1) é planej ada e projetada, o desenvolvedor de aplicaçãopode selecionar uma Visualização (definida em termos deObjetos de Dados) para ser uma Visualização direta. Taisdecisões de desenho podem ser especificadas através deferramentas de desenvolvimento de sistema, que serãomencionadas como "Ferramenta de ambiente de desenvolvimentounificado Dexterra" ou como a ferramenta de "Designer deadaptador Dexterra" (DAD). Tipicamente, o uso de umaVisualização direta por um cliente móvel é melhorimplementado como parte das condições de Filtro deVisualização para variáveis de clientes de modo a limitaros resultados retornados da fonte de dados de back-end paraser especifico ao usuário.

Quando a aplicação está rodando no cliente móvel,o cliente móvel solicitará dados de uma Visualizaçãodurante uma Solicitação de Objeto comercial (denominada umaoperação FindSet). O cliente móvel verá que a Visualizaçãoé uma Visualização Direta, e fará portanto a solicitação dedados da Visualização diretamente para o Servidor Dexterrautilizando o Gerenciador de Dados e passando quaisquervariáveis Definidas pelo Usuário ou Ambiente para o Filtrode Visualização. O Gerenciador de Dados recuperará osdados para a Visualização a partir da fonte de dados deempresa de back-end (que poderia ser um Tipo deVisualização Default, Derivada ou Delegada) e retornará osdados para o cliente, que então retornará os resultados darecuperação de dados para o Objeto comercial.

B. VISUALIZAÇÕES DERIVADAS

Uma Visualização Derivada prove a capacidade dederivar (extrair) uma definição de dados de uma ou maisVisualizações definidas no servidor de dados do sistema.Isso permite que um item de dados seja definido com base emuma ou mais estruturas de dados que são predefinidas comoVisualização. Uma Visualização Derivada incorporará

parâmetros de filtro e solicitará dados de um servidor querecupera um conjunto de base de dados associados em tempode execução a partir das fontes de dados de empresa e entãocoloca os dados recuperados em um motor de dadosrelacionais (RDE) que aplica os parâmetros de filtro deVisualização Derivada para extrair dados filtrados efornecer os mesmos para o tipo de Visualização Derivadasolicitante. Desse modo, Visualizações Derivadas podemfiltrar dados de uma ou mais outras Visualizações a partirde fontes de dados de empresa diferentes (como Siebel,Oracle, etc.) utilizando operações ANSI SQL comuns, dessemodo utilizando a potência de um motor relacionai comoServidor SQL ou Oracle.

Visualizações Derivadas são definidas emmetadados de sistema e são construídas em tempo de execuçãono Servidor Dexterra (que é sem estado) para fornecer aabstração de dados em vez de predefinir a estrutura comouma tabela ou objeto definido, dando flexibilidadeverdadeira para mudança na empresa.

Utilizando a Ferramenta de Ambiente deDesenvolvimento Unificado Dexterra, um desenvolvedor criaprimeiramente uma ou mais Visualizações de Base do tipoDefault, Delegada, ou Definida e configura condições defiltro, permissões e similares. Um tipo Default pode serdefinido para ser um dos tipos de Visualização restantes,como desejado. Após criação da Visualização de base, umaVisualização derivada pode ser criada pela seleção de umaou mais Visualizações e definição dos atributos daVisualização (como os campos) para mapear e a condição defiltro para aplicar para os dados retornados a partir dasVisualizações de base.

Em tempo de execução, o Servidor Dexterraresponderá a uma solicitação de Visualização Derivadaprimeiramente recuperando os dados das Visualizações debase da Visualização derivada e então colocará os dadosrecuperados em um motor relacionai como Servidor SQL ouOracle, e a seguir aplicará a Condição de Filtro deVisualização Derivada (como SQL) contra os dados eretornará os dados para fornecimento ao Gerenciador deDados para comparação e para preparação de fornecimentopara o cliente móvel.A Visualização Derivada é ilustrada na figura 5,que ilustra a operação de um sistema 502 com umaVisualização derivada (indicada como "V3" na figura 5) quese baseia em uma Visualização "VI" e uma Visualização "V2",de tal modo que a Visualização VI recupera dados de Clientea partir de um banco de dados Siebel 504 e a VisualizaçãoV2 recupera dados Históricos do banco de dados Siebel- AVisualização V3 especifica somente um subconjunto de dadosHistóricos para recuperação, que é realizado através decondições de filtro de V3. O subconjunto de dados é entãoretornado ao cliente móvel 506. A Visualização V2 é umtipo de Visualização Definida, em que somente umsubconj unto do histórico de ordem é solicitado pelaVisualização V2. O armazenamento de dados referenciais 508contém metadados a partir dos quais os dados especificadospodem ser recuperados; não contém dados brutos do históricode ordem. Desse modo, os dados que devem ser recuperados apartir do banco de dados 504 e retornados através dos linksde comunicação serão reduzidos, porque somente os dados deinteresse são efetivamente retirados do banco de dados eenviados para a Visualização Derivada V3.

C. VISUALIZAÇÕES DELEGADAS

A Visualização Delegada prove a capacidade dedelegar, ou cache, dados a partir de uma ou mais fontes dedados de empresa de back-end no Servidor Dexterra econfigurar o Servidor Dexterra para recuperar e atualizarseu cache com base em um conjunto predefinido de regras,como um intervalo de tempo (a cada hora, etc.) ou um eventopredeterminado (mencionado como acionamento de regra delado de servidor). Desse modo, uma Visualização delegadarecuperará periodicamente dados a partir das fontes dedados de empresa de acordo com parâmetros da VisualizaçãoDelegada e colocará os dados recuperados em um cache deMotor de Dados relacionai.

Utilizando a Ferramenta de Ambiente deDesenvolvimento Unificado Dexterra, um desenvolvedor criauma Visualização com base em um tipo de objeto suportadopor Adaptador especifico, como Tabela, Objeto, Procedimentoarmazenado, Script ou similar. O desenvolvedor configuraentão as condições de filtro, permissões e parâmetros deobjeto associados e então marca a Visualização como umaVisualização delegada e configura as funções de atualizaçãodo filtro, como intervalo de tempo de filtro, regras deeventos, e assim por diante. Posteriormente, em tempo deexecução, o Gerenciador de dados do Servidor Dexterrasolicitará automaticamente dados para a Visualização apartir do Adaptador definido no intervalo de tempo definidoou evento de lado de servidor e realizará cache dos dadosno RDE local.

Em resposta a uma solicitação de cliente móvel, oGerenciador de Dados do Servidor Dexterra recuperará osdados a partir do RDE local em vez de solicitar os dadosdefinidos pela Visualização a partir do Adaptador que éconectado à fonte de dados de empresa. Uma condição defiltro pode se aplicar à fonte de RDE local, desse modoaumentando o desempenho da solicitação e descarga da fontede dados back-end dependente para aquele conjunto definidode dados.

Desse modo, após o servidor executar recuperaçõesautomáticas de dados baseado nas funções de atualizaçãoespecificadas, solicitações subseqüentes de clientes móveispara dados de empresa podem ser preenchidas obtendo osdados solicitados a partir de cache RDE em vez dediretamente das fontes de dados de empresa, desse modoreduzindo o tráfego de dados entre o cliente móvel e asfontes de dados. Dados atualizados a partir de clientesmóveis são devolvidos diretamente para as fontes de dadosde empresa através dos Adaptadores.

D. VISUALIZAÇÕES DE DEFINIÇÃO

Uma Visualização de Definição prove a capacidadede criar uma Visualização definida por usuário na situaçãoonde não há armazenamento de dados back-end na empresa pararecuperar ou persistir os dados. Essa capacidade pode sercomumente utilizada para aumentar um sistema de back-endpara a funcionalidade exigida na oferta móvel que não fazparte do sistema de empresa. Outro uso poderia serpermitir que a empresa relacione dados da aplicação móvelcom dados nas fontes de dados de empresa de back-end semmodificar o sistema de empresa de back-end. UmaVisualização definida por Usuário (Visualização deDefinição) terá uma opção para "ServerOnly" ou"ClientOnly". A opção ServerOnly pode ser utilizada paraarmazenar dados para fins de aumentar um processo de dadosde back-end porém não exigido para a aplicação móvel. Aopção ClientOnly pode ser utilizada para armazenarelementos de dados adicionais a serem utilizados naaplicação móvel como listas de classificação, constantes,enumeração, e assim por diante.

Uma Visualização de Definição permite controlesobre onde dados recuperados são mantidos, no servidor dosistema ou no cliente móvel. A extensão de recursos desistema determinará genericamente a seleção entre as duasconfigurações.

Para utilizar Visualizações de Definição, umdesenvolvedor utili za a Ferramenta de Ambiente deDesenvolvimento Unificado Dexterra para criar umaVisualização pela definição da estrutura de dados,incluindo nomes de campo, tipos de dados, e valores defaultque armazenarão os dados comerciais. A seguir o

desenvolvedor pode criar um filtro bem como um conjunto depermissões para controlar acesso. A opção ServerOnly podeser selecionada, que não criaria a definição deVisualização em um dispositivo móvel. A definiçãoServerOnly seria uma Visualização de trabalhador utilizadapara outras operações, como uma Visualização Derivada. Adefinição ClientOnly criaria a Visualização no dispositivode Cliente somente. Se essa opção for selecionada, ousuário seria capaz de entrar dados de semente manualmente,importar dados a partir de uma fonte delimitada ou arquivoXML, e exportar os dados para um arquivo XML.

0 Servidor Dexterra utilizará a estrutura deVisualização Definida no RDE como sua fonte de dados back-end. No caso da opção ServerOnly, a definição deVisualização não será criada no cache de dados de clienteMóvel (SQLCE). No caso da opção de Default ou ClientOnly,a Definição de Visualização será criada como uma tabela nocache de cliente local (SQLCE). Se ClientOnly, serásemeada com os dados configurados no servidor (usuárioentrado ou importado).

E. MOTOR DE DADOS RELACIONAL

Em combinação com as Visualizações configuráveis,o sistema também inclui um motor de Dados Relacionai (RDE)na estrutura no servidor 406 (vide a figura 4) .Alternativamente, a RDE poderia ser localizada nos outroscomputadores do sistema de plataforma que podem secomunicar com o servidor. A RDE utiliza uma sintaxe padrãocomo ANSI SQL na comunicação em tempo real de dados de umaou mais fontes de dados empresa de back-end 4 08 para um oumais dispositivos de cliente móvel 402 em um modo semestado. Como descrito acima, a RDE é útil para

Visualizações derivadas, Visualizações Delegadas,Visualizações Definidas, e também é utilizada paracondições complexas de filtro, modelagem de estado declientes móveis, comparações de dados de clientes, esimilares. Isto é, a RDE é utilizada de acordo com ostipos específicos de Visualização, como exposto acima.

Como o Servidor Dexterra move dados de uma oumais fontes de dados de empresa de back-end para um ou maisclientes móveis, utiliza a potência da RDE para armazenaros dados em tempo real sem a necessidade de uma definiçãoestática de um mapeamento de modelo de dados para adefinição dos dados. A RDE é utilizada para tirar proveitoda potência de uma sintaxe de uso padrão como ANSI SQL parapromover a correlação de dados nas condições de filtro ouabstração de dados.

F. OBJETOS COMERCIAIS DE METADADOS

Para utilizar as Visualizações configuráveis eRDE, o sistema utiliza objetos comerciais de metadados quefornecem a capacidade de criar e definir um ObjetoComercial em meta dados que é ligado a uma ou maisVisualizações a partir de uma ou mais fontes de dados deempresa de back-end que podem ser utilizadas por uma oumais aplicações de cliente móvel utilizando o plug-inDexterra Studio VS.NET. Isso fornece a capacidade de criarrelações com um ou mais outros Objetos Comerciais para umaarquitetura de componente de aplicação orientada paraobj eto verdadeira utilizando o plug-in Dexterra StudioVS.NET.

O uso da RDE é obtido utilizando a Ferramenta deAmbiente de desenvolvimento unificado Dexterra paraconfigurar a definição de um Obj eto comercial incluindoPropriedades, Valores default, Relações, Condições defiltro, permissões, Aplicações associadas e Regrascomerciais. Em tempo de execução, o cliente móvel, apóssolicitação de um Objeto comercial, cria uma instância deobjeto com base na definição de metadados. Isso permiteque a aplicação de cliente execute então operações comoLocalizar, FindSet, Salvar, e Deletar. O cliente móvelexecutará essas operações contra os atributos deVisualização definidos para o Obj eto comercial. Isso poderecuperar ou atualizar dados no dispositivo local, porexemplo.

VII. CONFIGURAÇÃO E INTERFACE DE USUÁRIONa Estrutura de Adaptador no Servidor 430 daconfiguração da figura 4, uma Visualização não é limitadapor uma única tabela de dados, como seria o caso em umsistema sem a presente invenção (e como indicado na figura2) . Em vez disso, uma Visualização é limitada a um Objetode Dados com Comandos definidos para LER, ADICIONAR,ATUALIZAR, REMOVER e LER para EDITAR. Desse modo, umainterface de dados muito mais versátil é fornecida. Aestrutura de uma Visualização é definida pelas colunas dedados selecionadas especificadas no comando LER para oObjeto de Dados.

No sistema que utiliza a configuração de objetode Visualização da presente invenção, filtros são criadosem um Objeto de Comando, em vez de em um objeto deVisualização. A configuração dos Obj etos de Visualizaçãono servidor 430 permite abstração de operações CRUD (Criar,Ler, Atualizar, Deletar) visualização para as fontes dedados de empresa, e permite que CRUD seja definido em vezde hard coded. Diferente da configuração de Visualizaçãoalterada e alterações concomitantes como para criação defiltros, os componentes restantes ilustrados na figura 1podem ser utilizados para um sistema de plataforma móvelconstruído de acordo com a presente invenção.A figura 6 mostra uma representação diagramáticada arquitetura de dados para a plataforma móvel ilustradana figura 1 e compreendendo uma modalidade da presenteinvenção. A figura 6 mostra que um objeto de Visualizaçãodo sistema de dados tem um ViewID e é ligado a um Objeto deDados definidos. A figura 6 mostra que o Objeto de Dadospode incluir um ou mais comandos entre um comando LER, umcomando ADICIONAR, um comando ATUALIZAR, um comandoREMOVER, e um comando LER para EDITAR.

A figura 6 mostra que objetos de Comando tambémsão ligados aos Obj etos de Dados, e também são ligados aobjetos de Conexão que são por sua vez ligados a objetos deAdaptador. A figura 6 mostra que os objetos de Adaptadorrealizam interface com um armazenamento de metadados querealiza interface com as fontes de dados de empresa pararecuperar dados para a plataforma móvel, como descritoacima.

A figura 7 é uma representação diagramática daconfiguração de acesso de dados para a plataforma móvelconstruída de acordo com a presente invenção. A figura 7mostra que um cliente móvel (indicado como "ClienteDexterra" na figura 7) comunica-se com o servidor deaplicação ("Servidor Dexterra" na figura 7) através de umobj eto de Visualização no servidor, onde o obj eto deVisualização realiza interface com um Obj eto de Dados paraatuar através de obj etos de Comando para acessar obj etos deAdaptador que finalmente realizam interface diretamente comarmazenamentos de dados de empresa (por exemplo, servidoresde dados Siebel e Servidor SQL Microsoft na figura 7) . Nodispositivo do cliente, a aplicação móvel comunicasolicitações de dados através de um cliente inteligentepara armazenamentos de metadados e armazenamentos de dadoscomerciais para os objetos cie Visualização no servidor deaplicação.

A figura 8 ilustra como acesso aos recursos deDAD do sistema de plataforma móvel são obtidos através deum tipo de explorador de arquivo de interface de usuáriográfico. A figura 8 é uma foto de tela.de um display em umdispositivo de computador que está hospedando a aplicaçãodo programa de computador DAD. Na figura 8, o display é umdisplay do tipo janela, intitulado "Dexterra Explorer" emostra um espaço de trabalho com uma visualização de árvorede arquivo. A visualização de árvore mostra uma hierarquiade "Servidores" com nomes de servidor indicados comoSolomon, Tempest, Ultrium e thunder. Deve ser evidente quenomes de servidor podem ser selecionados de formaarbitrária.

De acordo com o programa DAD, uma variedade deações pode ser tomada com relação a um servidorselecionado. A figura 8 mostra que o servidor "Solomon"foi selecionado, com o item de menu de Acesso de dadossendo destacado para mostrar que opções de acesso de dadospodem ser investigadas. Embaixo do item de menu de Acessode Dados, sub-menus são mostrados, compreendendo Fontes dedados, Tipos de fonte de dados, Comandos, Objetos de Dadose Visualizações. Utilizando o programa DAD e o menuexplorador, um designer de aplicação móvel pode especificarnovas fontes de dados e podem realizar interface comAdaptadores correspondentes para obter acesso a fontes dedados de empresa para os clientes móveis que utilizarão aaplicação desenvolvida.

A figura 9 mostra um designer tendo "Tipos defontes de dados" selecionadas no menu de ExploradorDexterra e a figura 9 mostra que um menu de contexto égerado, fornecendo ao designer opções para acrescentar umnovo tipo cie fonte de dados, ou renova a visualização oueditar um tipo de fonte de dados, ou deletar um tipo defonte de dados. Desse modo, a seleção de um item de menuExplorer Dexterra pode gerar um menu de contexto quefornece um menu de operações adicionais no item de menuselecionado. A figura 10 mostra a seleção do item de menude Fontes de Dados a partir da figura 9, ilustrando fontesde dados exemplares disponíveis no sistema de acordo com odesenho. A figura 11 mostra seleção de um tipo de fonte dedados especifico, do qual um menu de contexto pode sergerado para editar operações no tipo de fonte de dadosselecionado. A figura 12 mostra tipos de Visualização quesão disponíveis para seleção. Como com os outros itens demenu de Dexterra Explorer, a seleção do item de menu deVisualização gerará um menu de contexto que permite que umdesigner execute operações de editar em tipos deVisualização, incluindo criar, editar e deletar.

Como observado acima, se o nó de "Fontes deDados" no menu Dexterra Explorer for selecionado, uma novaFonte de Dados pode ser especificada através de um menu decontexto que é gerada pelo programa Explorer. A figura 13mostra uma caixa de diálogo de Propriedades de Fontes deDados que é gerada pela utilização de um menu de contextode Fontes de Dados para criar um novo tipo de Fonte deDados. A figura 13 mostra que o designer é apresentado comuma tela que permite seleção de um adaptador de dados, combase nos tipos de dados disponíveis para o designer. Nafigura 13, os tipos de adaptador disponíveis são mostradoscomo OLE DB para Servidor SQL, OLE DB para Oracle,Adaptador Clarify e Adaptador Remedy. Esses tipos deadaptadores são mostrados para fins de ilustração somente;deve ser entendido que tipos de adaptador adicionais ediferentes poderiam ser fornecidos de acordo com osensinamentos da invenção. A figura 13 mostra que odesigner também pode especificar um tipo de Conexão. Apósselecionar um Adaptador, o designer selecionaria o botão dedisplay de Conexão para especificar os parâmetros deconexão.

A figura 14 mostra uma tela de autenticação parao designer para fornecer informações de registro e escolherum alvo de fonte de dados de empresa especifico. Após odesigner ser autorizado, o display será alterado de acordocom o adaptador selecionado. Após uma nova fonte de dadosser definida utilizando a interface DAD, um novo nó de tipode fonte de dados aparecerá na visualização de árvoreDexterra Explorer (figura 11), de acordo com o tipo defonte de dados recentemente definido do designer.

Outros nós podem ser criados, adicionados,editados e deletados da visualização de árvore DexterraExplorer. A figura 15 mostra um designer fazendo umaseleção de Comando a partir da visualização de árvore. Aseleção de "Adicionar novo comando" na figura 14 gera acaixa de diálogo de "Novo comando" da figura 16.

A figura 16 mostra que um nome pode ser entradopara o novo comando, juntamente com parâmetros paraespecificar fonte de dados, ação, tipo de dados, e fonte, etambém espaço para entrada de uma afirmação SQL. A figura17 mostra que o tab de Parâmetros do diálogo de ComandoAdicionar aceita especificações de comandos adicionais.

Entre os parâmetros de controle para a caixa dediálogo Adicionar Comando novo da figura 16, estão:

Caixa de texto de Nome de comando - o usuário DADentra um nome para identificar exclusivamente o comando.Em "salvar" há uma validação que o Nome de Comando éexclusivo.Fonte de dados - Essa é uma lista suspensa defontes de dados que foram definidas. Essa informação édescoberta de metadadòs. É necessário que cada comandotenha uma fonte de dados correspondente-

Tipo de comando (Ação) - essa é uma listasuspensa dos tipos diferentes de comandos disponíveis. Énecessário que cada comando tenha um tipo de comando.

Caixa de Grupo de dados - essa caixa de grupoinclui tabs para "Principal" e MParâmetros", e contém oscontroles para definir as ações do comando. Essa caixaserá diferente dependendo da fonte de dados escolhida. Porexemplo, o display ilustrado na figura' 16 é para um RDBMScomo Servidor SQL. Aqueles versados na técnica

reconhecerão que um sistema como um sistema Oracle/Siebelprovavelmente não teria a caixa de texto "Afirmação deSQL".

Botão de rádio do Tipo de fonte - a seleção dessebotão de rádio habilita as duas caixas combocorrespondentes (fonte de dados e tipo de fonte) edesabilita a caixa de texto de Afirmação SQL. Esse botãode rádio indica que o designer está utilizando os objetosde empresa disponíveis pelo sistema de dados de empresa.

Caixa de tipo de fonte - é uma lista que indicaos tipos de Objetos de Empresa disponíveis a partir dosistema de empresa. Um exemplo de tipos de fonte incluitabelas, visualizações ou procedimentos armazenados em SQL.

Caixa de fonte - uma lista suspensa dos obj et osde empresa disponíveis para o usuário selecionar com basena filtração por tipo.

Botão de rádio de afirmação SQL - a seleção dessebotão de rádio habilita a caixa de texto correspondente edesabilita as caixas de combo de Fonte e Tipo de fonte.Esse botão de rádio indica que o designer vai especificar aAfirmação SQL que esse comando executará.

Caixa de texto de Afirmação SQL - o designerentra uma afirmação SQL a ser executada pelo comando.

Entre os parâmetros para a caixa de diálogo deParâmetros - Adicionar novo Comando da figura 17, estão:

Caixa de lista de parâmetros - contém uma listade parâmetros para o Objeto de Empresa selecionado, seforem pertinentes. A figura 17 mostra parâmetros de Valorde Retorno e CustomerFirstName.

Caixa de grupo de Propriedades de parâmetro -mostra um agrupamento de controles que descreve aspropriedades do parâmetro selecionado.

Caixa de teste de nome - o nome do parâmetroselecionado. Na figura 17, essa caixa de texto é tornadacinza para indicar que está desabilitada porque o nome doparâmetro não pode ser editado.

Caixa de direção - essa contém uma lista suspensados tipos de direção que um parâmetro pode ter, comoEntrada, Saida e Entrada/Saida.

Caixa do tipo de dados - essa contém uma listasuspensa dos tipos de dados disponíveis para o parâmetro,se aplicável.

Caixa Necessária - contém os valores booleanosVerdadeiro ou Falso e desse modo indica se o parâmetro é ounão necessário.

Caixa de texto de valor - essa caixa de texto édisponível se um valor para o parâmetro for para serforçado.

Após conclusão do processo de edição, avisualização de árvore do Dexterra Explorer será atualizadapara refletir quaisquer itens adicionados. Por exemplo, afigura 18 mostra que um novo Comando denominado"customerquery" foi adicionado à visualização de árvore.Desse modo, o comando de nome estará disponível paraqualquer desenvolvedor subseqüente que utilize DA D pararealizar interface com o servidor Solomon. Deve serobservado que o novo comando CustomerQuery também pode sermanipulado (copiado, movido, editado e movido, etc.) paraoutro nó da visualização de árvore, utilizando os comandosde edição e interface de usurário gráfico DexterraExplorer.

Desse modo, a configuração de Objeto deVisualização descrita aqui suporta múltiplos tipos deVisualização para flexibilidade aumentada na operação daplataforma de dados móveis. A configuração de Objeto deVisualização nova suporta tipos de Visualização incluindoVisualização derivada, Visualização delegada, VisualizaçãoDireta e Visualização definida. Cada tipo de Visualizaçãofará interface com as fontes de dados de empresa com umafuncionalidade diferente, desse modo links de comunicaçõese recursos de fonte podem ser utilizados com maiorconveniência, flexibilidade e eficiência.

Desse modo, a ferramenta Dexterra Explorer provea capacidade de criar conectividade de empresa customizadapara fontes de dados de back-end diferentes, e prove acapacidade de separar a conectividade para qualquer sistemade empresa de back-end com a configuração e adaptação' àinstância especifica de uma implementação. Isso permiteque as comunicações entre a interface . NET e um sistemaback-end, sej am desenvolvidas separadamente a partir daconfiguração da informação necessária a partir do sistemaback-end, desse modo criando uma camada de abstração epermitindo que uma ferramenta de configuração gerencie aadaptação, como descrito aqui. Desse modo, a ferramentarevelada implementa uma Interface de Adaptador Dexterraespecífica que ligará ao Gerenciador de Dados Dexterra eexecutará entradas e saídas específicas necessárias nodeslocamento de dados entre o Servidor Dexterra e quaisquerdas fontes de dados de empresa.

A figura 19 é um diagrama de fluxo que ilustraoperação do sistema de plataforma de dados móveis comodescrito acima. Na primeira operação, representada nacaixa de diagrama de fluxo numerada 1902, o método deprocessar dados que são compartilhados entre múltiplasfontes de dados de empresa e um cliente móvel que secomunica com um servidor de aplicação começa com orecebimento de uma solicitação a partir de um cliente móvelpara uma operação de dados nos dados em uma das fontes dedados de empresa. Na operação seguinte, representada pelacaixa 1904, um Obj eto de Visualização configurável édeterminada, onde o Objeto de Visualização é adaptado paraser ligado a um Objeto de dados para execução de ações dedados de Objeto de Comando especificadas correspondendo àoperação de dados solicitada. Na última operação na caixa1906, as operações nos dados são executadas comoespecificado pelo Objeto de Visualização, utilizando ummotor de Dados relacionai.

A ferramenta de programa de computador mencionadaacima como "DAD" para uso por designers de aplicaçõesmóveis é fornecida para criar conectividade de empresacustomizada para fontes de dados de empresa diferentes dosistema de plataforma de dados móveis. A ferramenta deprograma de aplicação DAD prove esses recursos através dainterface de usuário ilustrada nos desenhos. Desse modo, aferramenta de programa de aplicação DAD prove um meio paraespecificar processamento de aplicação de dados que écompartilhado entre múltiplas fontes de dados de empresa eclientes móveis.O programa de computador compreendendo aferramenta DAD pode ser instalado em um sistema ouequipamento de computador, como um computador de mesa,computador notebook, ou similar, desde que o programa deferramenta DAD possa receber entrada de usuário pararealizar o processo de especificação de adaptador deconexão e possa verificar fontes de dados, ligações, esimilares. Os adaptadores configurados e Objetos deconexão podem ser incluídos em um sistema de plataforma dedados móveis e instalados em um servidor de aplicação daplataforma móvel como descrito acima, de modo que osrecursos operacionais dos adaptadores possam ser utilizadosnos clientes móveis para operações com as fontes de dadosde empresa.

Como descrito acima, a ferramenta DAD prove ummeio para configurar um Objeto de Visualização que proveoperações desejadas de dados em objetos de dadosarmazenados em uma fonte de dados de empresa de back end.Quando o Objeto de Visualização configurado é incorporadona plataforma de dados móveis, a plataforma de dados móveisrealiza suas operações em dados solicitados por clientesmóveis de acordo com o Objeto de Visualização especificado.Desse modo, o sistema de computador prove um Obj eto deVisualização configurável que é adaptado para ser ligado aum Objeto de Dados no sistema de computador para execuçãode ações de dados de Obj eto de Comando especificadas deacordo com o objeto de Visualização.

A presente invenção foi descrita acima em termosde uma modalidade atualmente preferida de modo que umentendimento da presente invenção possa ser passado. Há,entretanto, muitas configurações para sistemas de dados deempresa móveis não especificamente descritos aqui porém comos quais a presente invenção é aplicável. A presenteinvenção não deve ser portanto vista como limitada àsmodalidades especificas descritas aqui, porém em vez disso,deve ser entendido que a presente invenção tem amplaaplicabilidade com relação aos sistemas de dados de empresamóveis em geral. Todas as modificações, variações ouarranjos e implementações equivalentes que estãocompreendidas no escopo das reivindicações em anexo devemser portanto, consideradas compreendidas no escopo dainvenção.

Claims (17)

1. Estrutura de arquitetura de dados de sistemade computador para uso em um sistema de plataforma de dadosmóveis para processamento de dados que são compartilhadosentre múltiplas fontes de dados de empresa e um clientemóvel que se comunica com um servidor de aplicação, aestrutura de arquitetura de dados compreendendo:um Objeto de Visualização configurável no sistemade computador que é adaptado para ser ligado a um Objeto dedados no sistema de computador para execução de ações dedados de Objeto de Comando especificas de acordo com oObjeto de Visualização; eum motor de Dados relacionai que executaoperações em dados como especificado pelo Obj eto deVisualização.

2. Sistema de computador, de acordo com areivindicação 1, em que o Obj eto de Visualização é um tipode Visualização derivada no qual uma definição de dadospara dados solicitados é derivada de um ou mais Obj etos deVisualização no servidor de aplicação.

3. Sistema de computador, de acordo com areivindicação 1, em que o Obj eto de Visualização é um tipode Visualização delegada no qual dados solicitados sãorecuperados a partir de um armazenamento de cache delegadano servidor de aplicação.

4. Sistema de computador, de acordo com areivindicação 3, em que o armazenamento de cache delegadoprove dados aos quais uma regra de processamentopredefinida foi aplicada.

5. Sistema de computador, de acordo com areivindicação 1, em que o Objeto de visualização é um tipode Visualização de Definição no qual dados solicitados sãofornecidos de acordo com uma definição de dados do tipo deVisualização de definição.

6. Sistema de computador, de acordo com areivindicação 1, em que o Objeto de Visualização é um tipode Visualização direta no qual dados solicitados sãorecuperados diretamente de uma das fontes de dados deempresa.

7. Sistema de computador, de acordo com areivindicação 1, compreendendo ainda:um Objeto de conexão que prove uma interface parauma fonte de dados de empresa de back end e expõe um objetode interface de dados disponível através do Objeto deConexão como uma Tabela, Procedimento armazenado, Script ouobj eto;um Objeto de comando que executa ações de dadosespecíficos;um Objeto de Dados que permite que um cliente dedados móveis especifique uma das ações de dados de Objetode Comando a ser executado no obj eto de interface de dados;eum objeto de Visualização que é adaptado para serligado ao Obj eto de dados para execução das ações de dadosde Objeto de Comando especificadas.

8. Sistema de computador, ■ de acordo com areivindicação 1, em que as ações de dados incluem pelomenos uma ação entre ações de dados compreendendoSelecionar, Inserir, Atualizar e Deletar.

9. Método de processar dados que sãocompartilhados entre múltiplas fontes de dados de empresa eum cliente móvel que se comunica com um servidor deaplicação, o método compreendendo:receber uma solicitação de um cliente móvel parauma operação de dados em dados em uma das fontes de dadosde empresa;determinar um Objeto de Visualização configurávelque é adaptado para ser ligado a um Objeto de dados paraexecução de ações de dados de Objeto de Comandoespecificadas correspondendo à operação de dadossolicitada; eexecutar operações nos dados como especificadopelo obj eto de Visualização utilizando um motor de Dadosrelacionai.

10. Método, de acordo com a reivindicação 9, emque o Objeto de Visualização determinado é um tipo deVisualização derivada no qual uma definição de dados paradados solicitados é derivada de um ou mais Ob j et os deVisuaiização no servidor de aplicação.

11. Método, de acordo com a reivindicação 9, emque o Ob j et o de Visualização determinado é um tipo deVisualização delegada no qual dados solicitados sãorecuperados a partir de um armazenamento de cache delegadano servidor de aplicação.

12. Método, de acordo com a reivindicação 11, emque o armazenamento de cache delegado prove dados aos quaisuma regra de processamento predefinida foi aplicada.

13. Método, de acordo com a reivindicação 9, emque o Ob j et o de visualização determinado é um tipo deVisualização de Definição no qual dados solicitados sãofornecidos de acordo com uma definição de dados do tipo deVisualização de definição.

14. Método, de acordo com a reivindicação 9, emque o Ob j et o de Visualização determinado é um tipo deVisualização direta no qual dados solicitados sãorecuperados diretamente de uma das fontes de dados deempresa.

15. Método, de acordo com a reivindicação 9,compreendendo ainda:determinar um Obj eto de conexão que prove umainterface para uma fonte de dados de empresa de back end eexpõe um objeto de interface de dados disponivel através doObjeto de Conexão como uma Tabela, Procedimento armazenado,Script ou objeto de acordo com o Obj eto de Visualizaçãodeterminado;determinar um Objeto de comando que executa açõesde dados específicos de acordo com o Objeto de Visualizaçãodeterminado;determinar um Objeto de Dados que permite que umcliente de dados móveis especifique uma das ações de dadosde Obj eto de Comando a ser executada no obj eto de interfacede dados.

16. Método, de acordo com a reivindicação 9, emque as ações de dados incluem pelo menos uma ação entreações de dados compreendendo Selecionar, Inserir, Atualizare Deletar.

17. Sistema de computador incluindo uma estruturade arquitetura de dados para uso em um sistema deplataforma de dados móveis para processamento de dados quesão compartilhados entre múltiplas fontes de dados deempresa e um cliente móvel que se comunica com um servidorde aplicação, o sistema de computador compreendendo:meio para determinar um Obj eto de Visualizaçãoconfigurável no sistema de computador que é adaptado paraser ligado a um Objeto de Dados no sistema de computadorpara execução de ações de dados de Obj eto de Comandoespecificadas de acordo com o Obj eto de visuaii zação, emque as ações de dados incluem pelo menos uma ação entreações de dados compreende Selecionar, inserir, atualizar edeletar;meio para executar operações em dados comoespecificado pelo Objeto de visualização; eem que o meio para determinação comunica-se comum Ob j et o de conexão que prove uma interface com uma fontede dados de empresa back end e expõe um objeto de interfacede dados disponível através do Objeto de Conexão como umaTabela, Procedimento armazenado, script, ou Objeto,comunica-se com um Objeto de Comando que executa ações dedados específicos, comunica-se com um Objeto de dados quepermite que um cliente de dados móvel especifique uma dasações de dados de Objeto de Comando a ser executada noobjeto de interface de dados, e comunica-se com um Objetode visualização que é adaptado para ser ligado ao Objeto deDados para execução das ações especificadas de dados deObj eto de Comando.