Feeds:
Posts
Comentários

Padrões e Melhores Práticas para Integração ERP

24/08/2010 por magicsoftwarebr

Glenn Johnson – Senior Vice President – Magic Software Americas

Integração ERP pode ser definida como o processo de projetar, testar e implementar processos de negócios automatizados, orquestrando as conexões entre os sub-processos de um sistema de planejamento de recursos empresariais e os sub-processos de outros aplicativos de software corporativo, aplicações web, ferramentas de conteúdo, sistemas de e-mail/comunicação, mídias sociais e workflow humano.

Quando alguém aplica os princípios de integração ERP para um sistema ERP específico, isso pode se tornar conhecido como Integração SAP, Integração JD Edwards, Integração Peoplesoft, Integração Oracle eBusiness Suite (EBS), Integração Lawson, Integração Dynamics, Integração Sage, etc.

Melhores Práticas e Padrões de Integração durante a Implementação de Sistemas ERP

Plataforma agnóstica. Os sistemas ERP estão ligados a uma plataforma de aplicações ou ambiente específicos, tais como J2EE ou. NET e você também os executa em um sistema operacional específico. Sua integração de aplicações empresariais (EAI) e solução de gerenciamento de processos de negócios (BPM) deve ser capaz de trabalhar com todos os principais ambientes de computação e sistemas operacionais, incluindo Windows, Linux, UNIX e IBM i. Uma boa solução de integração ERP vai mesmo ser capaz de suportar os padrões de integração IBM i e padrões de integração de mainframe para aquelas organizações que executam aplicações nestes ambientes.

Modelagem e execução integradas. Muito freqüentemente, os analistas de negócio são forçados a modelar processos de negócios de alto nível usando uma ferramenta e executá-los usando soluções completamente diferentes, incluindo programação manual, pacotes de componentes java, ou soluções de EAI e BPM mal concebidas. Os gerentes de TI precisam ser muito cuidadosos aqui. Só porque a mesma marca, tais como IBM WebSphere ou Oracle Fusion Middleware, é aplicada a uma variedade de produtos diferentes utilizados para modelagem e integração pelos fornecedores, não significa que eles sejam integrados e projetados para trabalhar juntos. Ambas as marcas são conhecidas por ter usado uma estratégia de aquisições ao invés de uma estratégia de desenvolvimento unificado para ganhar mercado. Como resultado, suas ofertas para integração de aplicação e gerenciamento de processos de negócios são desconexas, confusas, sobrepostas e frustrantes para serem entendidas – e mais ainda para serem utilizadas.

Decisores de negócios devem ser extremamente cuidadosos com as recomendações que amarram sua integração ERP com estas soluções de integração desarticuladas e fraturadas de grandes marcas. Elas exigem numerosas compras de licenças de software e um exército de desenvolvedores e implementadores para realizar a integração. Não caia na “armadilha do mel”, método de vendas que convence que você precisa de apenas uma das muitas ferramentas de software avulsas oferecidas por estas marcas e, em seguida, prossegue com uma estratégia para vender mais e mais  produtos diferentes e desconexos que são agrupados sob a mesma marca, a fim de tentar forjar uma solução de trabalho.

Monitoramento e Design paralelos. Quando o monitor de integração utiliza a mesma interface visual que o estúdio de design de integração, fica muito mais fácil para seus gestores de TI monitorarem a execução de seus processos de negócios. Monitoramento e design paralelos significam que o fluxograma que você criou para seu projeto de integração é o mesmo que você utiliza para controlar sua execução. No estúdio de design você pode se aprofundar em qualquer componente para ver a sua configuração. No ambiente de monitoramento você pode se aprofundar em qualquer componente no fluxograma para acompanhar a sua execução.

Nenhuma Programação Manual. Há uma série de soluções de integração de aplicativos que destacam o fato de serem livres de código, ou que nenhuma programação manual é necessária. Isto só será útil se a solução o levar longe o suficiente na direção de seu objetivo final. Uma viagem gratuita de táxi que te deixa a vinte milhas de seu destino não tem nenhum valor. Uma solução de EAI que é livre de código, mas não pode adaptar-se à variedade de tecnologias em uso hoje, é igualmente de efeito muito limitado. Alguns vendedores podem mostrar uma demo estratégica de integração entre o JD Edwards EnterpriseOne e Salesforce.com, por exemplo. Mas eles realmente possuem os adaptadores de baixo nível necessários para integrar o JD Edwards World? Podem se integrar com aplicações legadas? Filas de mensagens? Fontes de texto não estruturadas? Eles podem funcionar com arrays multi-dimensionais? Será que eles possuem uma gama completa de operações lógicas incluídas em seus editores de expressão?

Equilíbrio entre Adaptadores de Alta Granularidade e Baixa Granularidade. É impossível para qualquer solução de integração de ERP ter adaptadores pré-construídos para todos os outros aplicativos que você pode possivelmente querer integrar. É por isso que é muito importante que a solução de integração ERP escolhida tenha os adaptadores tecnológicos necessários para realizar o trabalho. Isso significa muito mais do que ter suporte para bancos de dados e web services. Verifique atentamente para ver se a solução escolhida tem suporte para protocolos de comunicação, sistemas de arquivo, codificação / decodificação, redes e outras tecnologias de alta granularidade de baixo nível que te permitirão colocar em prática a integração necessária, sem recorrer à programação de interfaces para essas tecnologias. Qualquer analista de negócio que tenha experimentado a satisfação de realmente configurar uma solução de integração e não programá-la, entenderá este ponto muito claramente.

Aplicações compostas. Estas são as aplicações que são montadas utilizando tanto componentes de múltiplas aplicações existentes e adição de funcionalidades desenvolvidas especificamente, quanto serviços, tais como leitura de pedido do cliente, validação do status do cliente, cálculo do desconto ao cliente, ou aplicação de desconto ao pedido. Os componentes de uma aplicação composta são criados independentemente uns dos outros, sem o conhecimento ou análise dos diferentes modelos de informação que estão sendo usados. Na verdade, eles são independentes de plataforma, o que significa que o componente  que fornece algum serviço pode residir em qualquer plataforma capaz de fornecer tal serviço. Quando a integração ERP permite que o sistema ERP forneça serviços como parte de uma aplicação composta, você valoriza muito mais o seu investimento no ERP e começa a ver a recompensa prometida por fornecedores de ERP no início.

Arquitetura Fracamente Acoplada. Seu padrão de integração ERP deve incorporar arquitetura de baixo acoplamento com forte integração com o sistema ERP em si. Arquiteturas fortemente acopladas dependem umas das outras. Assim, alterações em qualquer componente podem (o que freqüentemente acontece) exigir mudanças em muitos outros componentes. Arquiteturas fracamente acopladas, em contrapartida, mantêm independentes os componentes que podem operar de forma independente. Uma arquitetura de baixo acoplamento permite substituir ou modificar componentes sem ter que fazer mudanças que refletem para os outros componentes. Desenvolvedores podem exigir a tecnologia correta para o trabalho sem ter que se preocupar com dependências técnicas. Na integração com ERP, você vai querer ter a certeza de que manterá os fontes do ERP e os destinos de terceiros separadamente (e vice-versa).

Componentes Stateless (sem estado). Os sistemas de ERP normalmente são capazes de múltiplas transações simultâneas. Isto é essencial para a escalabilidade da arquitetura. Quando um componente permite que mais de uma instância do componente esteja em uso simultaneamente e com estados separados, então ele é considerado um componente stateless. Isto tem a vantagem da escalabilidade e é vital para uma implementação robusta de arquitetura orientada a serviços e integração escalável de ERP.

Componentes Dinâmicos. Embora seja vantajoso ter componentes stateless em termos de dados de cada instância de execução, também é vantajoso ser capaz de configurar componentes de forma flexível para seu ambiente. Suponha que você está configurando a integração do Microsoft Dynamics CRM com o Oracle JD Edwards EnterpriseOne. Um sistema que utiliza componentes dinâmicos permitirá que você atualize a configuração do componente de forma a refletir quaisquer campos ou tabelas personalizados em uso nos ambientes de destino. O projeto de integração ERP é bastante simplificado quando os componentes utilizados podem ser passados em um pacote XML que configura a instância de execução. Um sistema de ERP que combina componentes sem estado e dinâmicos terá grandes vantagens, tanto no projeto concepção e execução.

Web Services. A Integração de ERP que utiliza Web Services pode vir a ter programação incrivelmente intensiva. Web Services programados manualmente também são difíceis de manter. Com Web Services nós estamos falando sobre o uso de protocolos padrão (como o WSDL, SOAP e UDDI) para “envolver”  serviços SOA, de forma que possam ser compartilhados com outras aplicações através da Internet. Este termo é freqüentemente usado como sinônimo de “SOA”, apesar de Web Services ser na realidade um mecanismo que permite SOA. Mas apenas porque estas tecnologias estão sendo utilizadas, isso não significa que você deve recorrer à programação delas. Uma boa solução de integração evitará completamente a necessidade de programar conexões para o seu sistema de ERP e outras aplicações, sistemas de comunicação e Web Services em seu ambiente.

Enterprise Service Bus. Um enterprise service bus é um mecanismo de mensageria distribuído baseado em XML, orientado a eventos – é um tipo de implementação de arquitetura orientada a serviços. É mais adequado para ambientes com servidor Wintel do que para ambientes de computação de médio porte, embora um sistema de médio porte possa certamente funcionar como um nó em uma implantação de enterprise service bus.

Sem um planejamento cuidadoso e a seleção de uma solução ágil de integração de processos de negócios orientada a eventos, a Integração ERP será cara, demorada e instável. Embora muitas empresas procurem evitar riscos, comprometendo-se com soluções de grandes marcas para integração, em vez disso eles estão expondo-se a maiores riscos e apenas evitando a culpa. É o fracasso destas grandes soluções para integração que inspirou a Magic Software a trazer a solução de integração iBOLT. Os wizards amigáveis ao usuário do iBOLT, as opções de arrastar e soltar, e as tabelas permitem criar conexões diretas com as aplicações corporativas implantadas em qualquer tecnologia de hardware, sistema operacional ou banco de dados. O resultado é uma arquitetura flexível e escalável que te permitirá fazer novas conexões, implementar mudanças e se adaptar rapidamente à necessidade sempre presente de mudanças em seu negócio.

Publicado em BPMS, Estratégia, Integração, SOA, iBOLT | Etiquetado , , , , , , | Deixar um comentário »

Criando Inteligência de Negócios através do Business Integration Suite

04/08/2010 por magicsoftwarebr

Hilton Menezes- Arquiteto de soluções Java/JEE na Add Technologies

Post originalmente publicado no Blog Add Tech

Introdução
O ambiente de negócios no qual as empresas operam atualmente está se tornando cada vez mais complexo. As empresas, privadas ou públicas, sentem crescentes pressões forçando-as a responder rapidamente a condições em constante mutação, além de terem que inovar na maneira como operam. Estas atividades exigem agilidade e tomada de decisão rápida e freqüente, sejam elas, estratégicas, táticas e operacionais. Tomar decisões pode exigir quantidade consideráveis de dados oportunos e relevantes, bem como informações e conhecimento. O processamento dessas informações, na estrutura das decisões necessárias, deve ser feito de forma rápida, com freqüência em tempo real e comumente exige um apoio computadorizado.

Diante deste cenário, cada vez mais empresas buscam na Tecnologia da Informação, soluções focadas em inteligência de negócios para tomada de decisões gerenciais. Neste artigo – dividido em 2 partes – apresentaremos uma solução de inteligência de negócios, através da criação de sistemas de informações corporativas e sistemas de informações geográficas.

O problema

Visando dinamizar a tomada de decisão sobre as obras de engenharia, a Prefeitura da Cidade do Rio de Janeiro (PCRJ), considerou a necessidade de georreferenciamento das informações existentes em seus sistemas legado no mapa digital do Município, sem que seja necessário realizar manutenção nas bases de dados existentes.

Como ponto de partida, foram eleitos dois sistemas que apóiam os processos de negócio da Secretaria Municipal de Obras (SMO) e da Secretaria Municipal de Habitação (SMH) respectivamente, realizando o controle e acompanhamento, inclusive orçamentário, das obras de engenharia da cidade.

A PCRJ definiu como escopo inicial, a análise das informações do Sistema de Acompanhamento, Controle de Obras e Serviços de Engenharia (SISCOB), do Sistema de Orçamento e Controle de Obras (ORC) e Sistema de Monitoramento e Acompanhamento (SIMA), sendo os dois últimos relativos a projetos habitacionais. O objetivo final é o georreferenciamento das informações de cada sistema no mapa digital do Município.

A solução

Para solução proposta, foram analisados alguns pontos importantes apresentados no problema, a saber:

1.A solução não poderia solicitar manutenção nos sistemas legado;
2.Deveriam ser lidas diversas fontes de dados, tanto em sistemas gerenciadores de banco de dados como em serviços web;
3.A nova massa de dados deveria ser utilizada por Sistemas de Informações Geográficas – SIG.

O maior problema encontrava-se em como ler os dados de diversas fontes, sem criar uma solução de alto custo, com agilidade e flexibilidade suficiente para adapta-se a mudanças nas estratégias de negócios.

Precisava-se utilizar uma ferramenta corporativa de integração (ESB) para criar uma base única, a ser utilizada por softwares de Sistemas de Informações Geográficas (SIG) e de Inteligência de Negócios (BI).


A resposta veio através da utilização do iBolt Business Integration Suíte da Magic Software Brasil, empresa parceira da ADD Technologies. O iBolt é um suite de integração flexível, com um ótimo custo-efetivo e de fácil uso, alavancando o investimento no legado, enquanto cria rápida e dinamicamente novos processos de negócios, serviços e aplicações. Seu design poderoso e simplificado – que não requer virtualmente nenhuma habilidade de programação – assegura as empresas, integração de negócios rápida e bem sucedida, enquanto gera um rápido retorno sobre o investimento (ROI), aumentando o rendimento e a satisfação do cliente.

Neste momento iremos conhecer o resultado do projeto e o que foi gerado de valor para o cliente.

iBolt contêm diversos conectores para SGBDs, sistemas SAP, Web Services, Salesforce, ERP, Serviços de E-mail, Enterprise Java Beans, Microsoft Office, SNMP, Google Docs, JDEdwards, HTTP, classes Java, Lótus Domino, XML, Websphere MQ, Microsoft MQ, Java Message Sevice, FTP, dentre outros, prontos pra uso. É só “plugare-usar”. Dessa forma diminui-se o custo do projeto e proporciona-se flexibilidade necessária em caso de mudança nas regras de negócios.

O Resultado

A organização administrativa do município do Rio de Janeiro divide-se em Bairros, Regiões Administrativas (RA) e Áreas de Planejamento (AP). No entanto, alguns registros de obras deveriam ser georreferenciados pelo seu logradouro mais número predial ou número do logradouro, por exemplo, obra de manutenção na “rua voluntários da pátria, 5678”

Segue abaixo alguns problemas encontrados no projeto e sua resolução no iBolt:

Problema Solução
Os nomes dos logradouros não tinham um padrão comum de tipos Foi importado um arquivo CSV com os tipos padrões e feito a conversão durante a leitura dos sistemas legado
Os códigos dos logradouros são fornecidos via serviços web por outro órgão Foi criado um fluxo específico para consulta de códigos de logradouros a partir de composição do nome do logradouro nos serviços web. A lógica do fluxo permite filtrar o bairro retornado pelo serviço web.
Os números de logradouros (numeração predial) estavam em campos alfanuméricos sem um padrão determinado Foram criadas regras de negócios e extratores, que filtravam o número a partir de um conjunto de caracteres alfanuméricos. O resultado foi gravado em outra coluna, permitindo que a PCRJ pudesse observar quais registros foram limpos.

A PCRJ repassou 4320 registros como amostra de dados. A solução e mostrou eficiente, uma vez que como resultado, obteve-se 100% dos dados de obras dos sistemas legados, tratados e com possibilidade de georreferenciamento pelo Sistema de Informação Geográfica da PCRJ.

Segue números do resultado final:

• 1115 registro com referência de logradouros, sendo 592 tratados pelo iBolt, tornando-os georreferenciáveis pela dupla  logradouro e número predial. Os 523 não tratados, foram georreferenciáveis pelo bairro.
• 1441 georreferenciados por Bairros, pois não continham informações de logradouros
• 233 georreferenciados por RA, pois não continham informações de logradouros nem bairros
• 1531 georreferenciados por AP, pois não continham informações de logradouros, nem bairros, nem RAs.

Segue abaixo o conjunto de ilustrações retiradas do Sistema de Informações Geográficas da PCRJ a partir da leitura da base da dados SIG gerada pela solução proposta pela Add Technologies.

Ilustração 7 – Obras por bairros

Ilustração 8 – Obras por RA

Ilustração 9 – Obras por AP


Conclusão

A solução proposta pela Add Technologies, resolve o problema de georreferenciamento das informações existentes nos sistemas legado da PCRJ em um mapa digital do município do Rio de Janeiro, sem que seja necessário realizar manutenção nas bases de dados existentes.

Não obstante, o uso do iBolt - Business Integration Suíte como ferramenta corporativa de integração e de gerenciamento de processos de negócios, permitiu estender a solução para atender outras áreas de negócios, bem como, a leitura de dados por Sistemas de Informações Corporativas, alavancando a solução em não somente um ferramenta de integração, mas também em uma solução que permite Inteligência de Negócios, uma vez que fornece informações cruciais a sistemas de apoio a decisão.

Publicado em BPMS, Integração, SOA, iBOLT | Etiquetado , , | Deixar um comentário »

O Impacto da indisponibilidade de software na eficiência das empresas

22/07/2010 por magicsoftwarebr

Glenn Johnson – Senior Vice President – Magic Software Americas

Hoje, o software já faz parte do cotidiano das empresas. Se a informação é o seu negócio ou se você simplesmente precisa de informações sobre ele, o software fornece o que você precisa. Então por que tantas empresas reduzem sua eficácia operacional, tentando sobreviver com menos licenças de software do que realmente precisam?

A falta de software disponível para os trabalhadores em sua organização, traz graves, e muitas vezes ocultas consequências ao negócio. Enquanto os gerentes podem pensar que estão ajudando os seus negócios, limitando o número de licenças de software para “apenas aqueles que realmente precisam”, em vez disso, eles podem estar reduzindo a eficácia operacional em detrimento de seus negócios. O acesso insuficiente ao software aumenta o custo da má qualidade (COPQ) em um negócio.

Considere estas consequências da insuficiência de software:

Formação inadequada e aculturação. Em muitas organizações, o processo na contratação do funcionário não incluiu a providência prévia de acesso aos softwares necessários. Como resultado, os programas de formação inicial erram o alvo ou ensinam comportamentos menos eficientes do que os possíveis quando as aplicações de software corretas estão disponíveis. Funcionários mal treinados podem oferecer um serviço pobre ao cliente, cometer um maior número de erros e afetar negativamente a moral dos funcionários.

Período inicial de ineficiência. Quando as licenças não estão disponíveis para os novos funcionários, mesmo após o seu período de treinamento inicial, a perda econômica ocorre durante o período de espera para entrar no “sistema”. Até então, salários são gastos em trabalhadores menos eficientes e os maus hábitos de trabalho são mais incentivados.

Outsourcing e In-Sourcing indevidos. Quando trabalhadores especializados que poderiam fazer um trabalho, e não o fazem porque não têm acesso ao software, eles são obrigados a submeter a tarefa a outra pessoa. Isso pode resultar em um outsourcing externo com custo. Quando uma outra empresa é necessária para fazer um trabalho que poderia ser feito se o software estivesse disponível para aquela pessoa, ocorrem custos extras e atrasos. Frequentemente, transferir uma tarefa para outro trabalhador significa transferi-la para outra empresa. Estas transferências criam atrasos, introduzem maior oportunidade para a falta de comunicação e são inerentemente ineficientes por causa das comunicações circundantes desnecessárias, solicitações e revisões do processo.

Trabalho duplicado. Algumas empresas mantêm duas aplicações de software distintas para executar a mesma tarefa, essencialmente, porque eles não possuem licenças de software suficientes para todos os trabalhadores para que utilizem um único sistema. Alguns trabalhadores estão no antigo sistema, enquanto outros estão no novo. Muitas vezes, nessas organizações, há um funcionário que passa horas por semana reinserindo dados ou executando tarefas em lote para sincronizar sistemas – que poderiam ser evitadas através de um trabalho em um único sistema.

Estrangulamentos. Quando somente alguns dos que precisam de acesso efetivamente o possuem, ocorrem gargalos. Atividades importantes são desnecessariamente atrasadas porque o processo está dependente de um número limitado de pessoas que têm acesso ao aplicativo adequado. Alguns trabalhadores podem estar compartilhando uma licença, o que significa que apenas um trabalhador tem acesso ao software a qualquer momento. O tempo de espera para a licença ficar disponível cria necessidade de comunicação, acrescenta atrasos e cria gargalos.

Excesso de pessoal. Quando um aplicativo de software é incorretamente rotulado como uma especialidade e trabalhadores de conhecimentos específicos são contratados para operá-lo, o resultado é o excesso de pessoas. O aumento das necessidades de mão-de-obra especializada muitas vezes pode ser evitado com o simples aumento da disponibilidade do software e treinamento de mais trabalhadores sobre o uso do mesmo. Às vezes, estas ineficiências em excesso também podem ser necessárias devido a uma gestão excessivamente restritiva de direitos de usuário dentro de um aplicativo. O usuário pode ter uma licença, mas não tem os direitos de usuário necessários para executar a tarefa. O impacto econômico é o mesmo.

Moral reduzido dos funcionários. No mundo de hoje das mídias sociais, aplicações ricas, integração e mesclagem de software em tempo real, a falta de acesso às aplicações pode ser extremamente frustrante para os trabalhadores e provocar a redução da moral dos funcionários e um maior turnover.

Falta de Enriquecimento Interdepartamental. Existe um custo negativo, quando os vendedores não estão cientes dos problemas de atendimento ao cliente, porque eles “não estão no sistema” que acompanha os problemas e soluções do atendimento ao cliente. Estender software e o acesso à informação para além das tradicionais fronteiras departamentais pode melhorar os processos de negócio. Quando a equipe de engenharia pode acessar diretamente o sistema de apoio ao cliente, eles podem ser capazes de propor soluções imediatas ou mesmo detectar defeitos do produto mais cedo do que quando eles não têm acesso e devem confiar nos relatórios mensais ou outros meios de compartilhamento de informações entre os departamentos.

Processos de Negócio Ineficientes. Talvez o resultado da falha no uso de software ou utilização de software inadequado seja o custo de um processo de negócio ineficiente. A maioria das organizações passa por um treinamento inicial sobre “como” utilizar um aplicativo de software. As instruções iniciais normalmente abrangem o desempenho de tarefas básicas. Sem um treinamento mais avançado sobre “quando fazer” e “por que” usar o software, os processos são executados ad-hoc ou sem o benefício integral da eficiência incorporada ao sistema de software. A subutilização de software tem graves consequências econômicas em todas as funções departamentais de uma organização: administração, finanças, engenharia, produção, marketing, vendas, distribuição, serviços e operações.

Desvantagens competitivas. Organizações que subutilizam softwares e restringem o número de licenças ficam à mercê de concorrentes que operam na máxima produtividade e eficiência reforçada por softwares. Organizações que operam sem um número suficiente de licenças de software ficarão para trás na inovação, tempo de resposta ao mercado, participação de mercado, capacidade de produção, satisfação do cliente e performance dos resultados financeiros.

A insistência nos caros estudos formais de ROI e relatórios de uso pode incorrer em uma lista longa e geralmente esconde custos nas empresas, que podem ser facilmente evitados, bastando ter uma visão mais agressiva em relação à disponibilidade e utilização de software. O software que funciona vale cada centavo do seu custo de licenciamento. Cloud computing não elimina o problema, na verdade, agrava-o. Quando o software é visto como uma despesa operacional ao invés de uma despesa de capital, crescem as pressões para limitar o seu uso. Empresários inteligentes terão certeza de que têm licenças de software suficientes disponíveis para todos os seus usuários, incluindo as licenças suficientes para o crescimento futuro. De quantas licenças você precisa?

Publicado em BPMS, Cloud Computing, Estratégia, Integração, RIA | Etiquetado , , | Deixar um comentário »

Integração RIA com text-to-speech (TTS) em menos de 4 minutos

20/07/2010 por magicsoftwarebr

Confira na sessão Dicas e Truques a contribuição de Ofer Spiegel- Diretor de Marketing de Produto da Magic Software Enterprises

Para aqueles que estão interessados em ver como o serviço .NET text-to-speech (TTS) pode ser integrado em no uniPaaS RIA, eu preparei este pequeno clipe para demonstração (leia a dica completa)

Publicado em Integração, RIA, uniPaaS | Etiquetado , | Deixar um comentário »

Aplicações móveis e Cloud Computing- Tendências para 2010/11

15/07/2010 por magicsoftwarebr

Sam Green – The Creative and Content Manager at Magic Software

Tive recentemente, a oportunidade de entrevistar Eyal Pfeifel, CTO da Magic Software e perguntá-lo sobre sua opinião à respeito das inúmeras tendências tecnológicas na qual a empresa está trabalhando no momento, incluindo Rich Internet Applications (RIA), desenvolvimento de aplicações empresariais móveis e todo o fenômeno do Cloud Computing. Veja abaixo a entrevista completa:

SG: Nossas plataformas são conhecidas por serem muito mais “prontas para os negócios” do que dependentes de codificação complexa. Você poderia nos detalhar esse aspecto?

EP: Quando desenhamos o uniPaaS, nossa principal meta era torná-lo eficiente e simplificar o processo de desenvolvimento de aplicações de negócios. Sempre que consideramos adotar ou desenvolver novas capacidades, enfatizamos na facilidade de uso e não necessariamente em um número exaustivo de funções. No final do dia, o desenvolvedor percebe uma experiência mais produtiva que é resultado desse nosso foco.

SG: Defina as principais vantagens das Rich Internet Applications (RIA).

EP: Durante anos, departamentos de TI e ISV’s vêm procurando por tecnologias que não requeiram manutenções futuras, mas que ainda assim, sejam poderosas e interativas. O principal sucesso por trás do browser foi sua habilidade de disponibilizar aplicações para qualquer desktop sem solicitar nenhuma instalação ou manutenção. No entanto, aplicações no browser são muito complicadas de desenvolver se você deseja atingir um alto nível de interatividade. É aí que o RIA preenche esta lacuna, oferecendo uma interface rica de alta interatividade, não requerendo nenhuma instalação ou administração.

Eyal Pfeifel, CTO da Magic Software

SG: Quais são alguns dos desafios em construir efetivamente uma aplicação empresarial móvel?

EP: O principal desafio enfrentado pelos desenvolvedores hoje, é o grande número de plataformas de desenvolvimento móvel orientadas para os negócios. Cada plataforma móvel hoje, necessita de uma habilidade e de ferramentas de desenvolvimento completamente diferentes e o desenvolvedor precisa escolher entre focar em alguma ou aprender todas. Estes ambientes de desenvolvimento existentes são também comparáveis à primeira geração de plataformas de desenvolvimento para o desktop de uma década atrás, em termo de funcionalidade e simplicidade.

SG: Então como fazemos para contornar estas dificuldades hoje?

EP: Utilizando nossa plataforma uniPaaS é possível desenvolver ambas as aplicações móveis e de desktop usando um único ambiente de desenvolvimento e apenas um paradigma. O mesmo leque de habilidades que o desenvolvedor usa para construir aplicações para o desktop podem ser usados agora, também para criar aplicações móveis. O suporte do uniPaaS para plataformas móveis adicionais irá se expandir muito em um futuro próximo.

SG: Para que caminho você vê o mercado móvel se direcionando daqui pra frente?

EP: Nos próximos anos, veremos mais funcionalidade se movendo do escritório para o telefone celular, assim como migramos do telefone da empresa para números de telefone privados e de emails no nosso desktop para emails nos dispositivos móveis. Nós veremos agora também, habilidades adicionais das empresas migrando do desktop para os aparelhos móveis onde melhor forem aplicadas.

Algumas capacidades podem obviamente, permanecer no desktop, mas funções que requeiram interação e respostas individuais irão mover-se, assim como gerenciamento de tarefas, fluxo de trabalho, simples relatórios e coisas do tipo.

SG: Então, você vê todas as aplicações de TI movendo para as “nuvens” nos próximos anos?

EP: Acredito que a nuvem é uma plataforma muito importante e acredito que muitas soluções empresariais irão migrar para ambientes baseados em Cloud Computing nos próximos anos. No entanto, como condição para que esta tendência de concretize, é vital proporcionar opções locais para ambos os departamentos de TI e ISV’s, ao invés de se concentrar só em evitar preocupações com tecnologia. Qualquer vendedor buscando o sucesso no ambiente das nuvens seria um sábio se disponibilizar capacidades locais também.

Publicado em Cloud Computing, Estratégia, Mobile, RIA, SOA, SaaS, uniPaaS | Etiquetado | Deixar um comentário »

Utilizando um Sistema de Controle de Versões com uniPaaS

08/07/2010 por magicsoftwarebr

Confira na sessão Dicas e Truques a contribuição de Glenn Johnson- Senior Vice President at Magic Software Americas

Um Sistema de Controle de Versões (VCS) mantém um conjunto organizado de diferentes versões de arquivos que são criados ao longo do tempo como parte de um projeto de desenvolvimento uniPaaS. Com um VCS,…(leia a dica completa)

Publicado em iBOLT, uniPaaS | Etiquetado , , , | Deixar um comentário »

O Poder da Escolha: Desenvolvendo Aplicações Cliente-Servidor

29/06/2010 por magicsoftwarebr

Glenn Johnson – Senior Vice President – Magic Software Americas

Quando falamos em uniPaaS Magic Software, você vai ouvir muitas vezes nos referirmos ao “Poder da Escolha.” É importante ressaltar que o Poder de Escolha inclui como primeira escolha: o modo cliente-servidor de implantação de aplicativos, às vezes chamado de full client ou open client. A Magic Software está plenamente consciente do forte engajamento de muitos desenvolvedores com o paradigma cliente-servidor e é orgulho a nossa liderança entre  plataformas de aplicações cliente  servidor. O paradigma cliente servidor pode evoluir e melhorar, mas não irá desaparecer. O fato de a mesma plataforma de aplicações fornecer opção para programação e implantação de aplicações Web e  RIA é parte do poder da escolha, mas a primeira escolha de fãs da arquitetura cliente-servidor, é clara.

Uma das áreas chave de escolha na criação de aplicações cliente-servidor é de que todos os controles GUI estão disponíveis no uniPaaS. Os controles GUI uniPaaS  utilizados na programação cliente-servidor são: ActiveX, Check Box, Column, Combo Box, Edit, Horizontal Slider, Image, Line, List Box, OLE, Push Button, Radio, Rich Edit, RTF, Static, Subform, Tab, Table, Tree e Vertical Slider. Com a aplicação cliente-servidor, o desenvolvimento de tarefas interativas e subformulários dá a você um grande controle sobre a interface do aplicativo.

Você pode utilizar um controle de subformulário para integrar uma tarefa de formulário dentro do formulário de outra tarefa, enquanto mantém os dados da tarefa do subformulário movimentando e registrando ciclos de atividades, independente da tarefa pai.

The Power of Choice

Pode-se ver uma série de vantagens ao usar subformulários para o desenvolvimento cliente-servidor. Obviamente, com subformulários você pode estacionar na linha de uma tarefa de pai e ver os detalhes da subtarefa. Isso dá a você o que pode ser descrito como uma relação de uma tarefa para muitas. Além disso, o uniPaaS atualiza automaticamente os dados do subformulário de visualização de dados de acordo com a tarefa pai somente ao passar parâmetros. O uniPaaS também mantém a sua última posição na visualização de dados do subformulário quando você sai e entra novamente. Finalmente, um tab cycle é fornecido para a tarefa subformulário. Vendo por completo você tem um nível muito mais detalhado da interação que é possível. E sim, claro, todo o controle desta GUI está dentro do modo cliente-servidor.

O comportamento do runtime de um subformulário é bastante previsível. No runtime, você pode guiar para o subformulário ou clicar na área da janela do subformulário. O motor de runtime irá estacionar  no primeiro controle na subtarefa. Ao clicar em um local estacionável, o motor do runtime move-se para a subtarefa e estaciona no controle selecionado, que aciona o mecanismo de execução para executar a tarefa de Task Prefix, Record Prefix, e operações Control Prefix. Ao clicar em um local não-estacionável, o motor do runtime move o foco para o subformulário tarefa e estaciona  no primeiro controle estacionável lá.

Quando o motor do runtime instrui o subformulário tarefa para terminar através de um evento Close, clicando fora da área do subformulário, ou por uma condição  End Task, o motor do runtime executa as operações Control Suffix, Record Suffix, e Task Suffix. O foco retorna para o próximo controle na tarefa pai, conforme determinado pela tabbing order e tabbing direction. (Esses comportamentos são diferentes, é claro, no modo RIA).

Quando você retorna para a subtarefa e a exibição de dados não foi atualizada, isso significa que o Range, Locate, Sort, Key, e o Link Join ou Link Outer Join não foram modificados. A subtarefa mantém a mesma página ou registro, que foi exibido pela

última vez. Nenhum tratamento é necessário para uma subtarefa quando a tarefa principal está fechada porque a subtarefa fecha automaticamente quando a tarefa dos pais se fecha.

Para saber mais sobre o desenvolvimento de aplicações cliente-servidor em uniPaaS, baixe o curso online gratuito “Introdução ao uniPaaS Open Client” da Magic University.

Publicado em Cloud Computing, Estratégia, Mobile, RIA, SOA, SaaS, uniPaaS | Etiquetado , | Deixar um comentário »

Desenvolvimento de integração com JD Edwards requer a ferramenta correta para o trabalho

22/06/2010 por magicsoftwarebr

Glenn Johnson – Senior Vice President – Magic Software Americas

Imagine que a você tenha sido atribuída a tarefa de gerenciar o desenvolvimento de uma interface JD Edwards para a sua empresa, e agora? Você chama a Oracle, um integrador de sistemas, ou faz você mesmo?

Desenvolver interfaces JD Edwards exige consciência dos padrões de integração disponíveis para a versão do JDE e versões das ferramentas a serem integradas. A versão utilizada suporta objetos de negócios? Os processos necessários estão disponíveis? Quais módulos precisam ser interligados?

Vamos assumir por um momento que você tem uma versão antiga do JD Edwards World, sem suporte para objetos de negócios (vamos chegar ao outro caso mais tarde). Você tem opções além de escrever programas de RPG? Sim. Com o iBOLT Special Edition para JD Edwards (JDE Connect) você pode desencadear e orquestrar processos de negócios que abrangem aplicações, sistemas, pessoas e websites utilizando para a integração, uma abordagem arrastar e soltar, e configurar. Em outras palavras, um analista de negócios ou arquiteto pode executar o trabalho, sem recorrer à programação do código linha por linha. Quando os objetos de negócios são uma parte dos objetivos da integração, então o iBOLT pode fazer interface diretamente para as funções de negócios do Enterprise One (E1), por exemplo, independente de que módulo ou módulos são o alvo.

O primeiro passo é definir a sua topologia para fins de referência e para se certificar que você está usando uma convenção de nomenclatura padrão de notação. O segundo passo é mapear em alto nível o processo de negócio desejado. Chegar ao ponto em que você está pronto para mapear o processo de negócio é uma das maiores fases do seu projeto. Esta é a fase de coleta de requisitos, onde ocorre a análise de negócios em grande parte fora do sistema de integração. Uma boa sessão de “quadro branco” com uma ampla oferta de post-it para notas pode ser uma forma eficaz para descrever o que é e como é o processo de negócios desejado. Exceto que, quando você começa a documentar visualmente esses fluxos de negócios, você pode agora começar a gravá-los digitalmente no Business Process iBOLT Editor.

Tenha em mente que você está procurando identificar os eventos que disparam os fluxos de processos de negócios. Que eventos devem ser utilizados para disparar eventos? Atividade de banco de dados, e-mails pré-formatados, serviços web, exame de diretório para arquivos novos ou modificados, etc? Tenha em mente que um fluxo de negócios pode ter vários gatilhos, incluindo a realização ou uma saída lógica a partir de um fluxo diferente.

Cada fluxo normalmente deve conter as condições de execução, ações permanentes, verificação da validade, condições para a ação, saídas de fluxos de exceções e gerenciamento de status. O iBOLT Special Edition para JD Edwards irá permitir-lhe gerenciar tudo isso a um nível elevado para que o foco esteja na lógica do negócio. Não há programação envolvida. Isto é possível devido ao fato do iBOLT possuir uma biblioteca de componentes pré-construídos que são totalmente configuráveis por um analista de negócios usando uma interface gráfica (Windows). Os componentes disponíveis incluem não apenas os adaptadores para aplicação JD Edwards, mas também incluem uma robusta biblioteca de adaptadores sem a necessidade de investimentos extras. A biblioteca de componentes do iBOLT inclui componentes para .NET, Call COM, COM, Directory Scanner, Domino, uniPaaS (eDeveloper), EJB, e-mail, Encryption, File Archive, File Management, File Splitter, FTP, HL7, HTTP, iBOLT Portal, iSeries Connector, ItemField Connector, Java Component, JD Edwards Connector, JMS, Microsoft Excel, Microsoft Word, MSMQ, Notes DB Connector, Salesforce Connector, SAP Business One, SAP R/3, UPS, W4, Web Services, WebSphere MQ, XSLT e outros. E claro,  trabalha com todos os tipos de bancos de dados e possui uma extensa biblioteca de métodos e wizards, incluindo um poderoso data mapper.

Tenha em mente que o iBOLT Monitor irá monitorar a execução de seus fluxos. Você pode utilizar esta monitoração do status do fluxo para executar outros fluxos e alertas. Os processos estão falhando devido à falta de conectividade? Inicie um fluxo de recuperação. Os volumes de transação estão anormalmente altos ou baixos? Envie um alerta para um usuário-chave ou administrador do sistema.

Com um bom projeto dos fluxos de integração desenhado, a Interface JD Edwards que você desenvolveu está pronta para ser testada. O teste pelo analista de negócios é possível usando o modo de emulação do iBOLT. Depois que você está satisfeito com os testes pelo departamento de TI, fazer testes de aceitação com o usuário é vital. Será que os processos de negócios recém-orquestrados cumprem as metas e objetivos definidos durante a fase de coleta de requisitos de negócio e sua sessão de brainstorm?

Os fundamentos das melhores práticas não mudam muito de um projeto de TI para o outro. Mas as ferramentas disponíveis para integração e desenvolvimento de interface do JD Edwards podem fazer toda a diferença. Independente de saber se você decide entrar em contato com um integrador de sistemas ou fazer você mesmo, os usuários de JD Edwards usuários são aconselhados a investigar o iBOLT Special Edition para JD Edwards. A integração de JDE não tem que envolver um arriscado projeto de programação.

Acesse o Integrate JD Edwards With SharePoint White Paper aqui.

Publicado em Integração, SOA, iBOLT | Etiquetado , , | Deixar um comentário »

Variáveis “Estáticas” no eDeveloper / UniPaaS

16/06/2010 por magicsoftwarebr

Confira na seção Dicas e Truques a contribuição de Manoel Frederico da Silva.

Publicado em uniPaaS | Etiquetado , | Deixar um comentário »

A integração de aplicativos cloud com sistemas legados

07/06/2010 por magicsoftwarebr

David Akka

David Akka – CEO - Magic Software UK  

Em um artigo recente e muito bem escrito, intitulado “Cloud Computing: o que os CIOs precisam saber sobre Integração”, Kim Nash – CIO.com editor sênior – entrevistou CIO’s e CTO’s que estavam dispostos a compartilhar a sua experiência de computação em nuvem. Um dos problemas comuns que todos eles descreveram foi a questão da integração dos sistemas legados com aplicações em nuvem. Lorraine Lawson refere-se a esta questão como o calcanhar de Aquiles do Cloud Computing em Os únicos e não-tão-únicos desafios da Integração. A pergunta é: por que um dos passos fundamentais para funcionar eficazmente na nuvem é tão difícil? Existe uma maneira de tirar essa dor? A resposta  é sim, pura e simplesmente, e chama-se iBOLT.

Se tomarmos o exemplo do artigo de Nash, podemos ver qual é o problema. Nash entrevistou Stuart Appley, CIO na Shorestin Properties. Eles usaram “uma versão hospedada de um sistema chave de gestão, da Yardi Systems, sendo que o  Yardi é executado em um servidor IBM (IBM) AS/400. Quando ele quis versões em nuvem de outras aplicações para troca de dados com o software Yardi, nenhum fornecedor dos aplicativos nem a Yardi tinha um utilitário escrito especificamente para ligar seus sistemas. A equipe da Appley tinha que escrever interfaces em RPG, a linguagem de programação que a IBM usa no AS/400. Isto pode parecer uma solução simples para um problema pequeno, mas aqueles que tentarem saberão que escrever uma interface entre duas aplicações não é rápido nem simples e o que será, se você tem dezenas de aplicações?

A manutenção e modernização de sistemas legados tornaram-se um dos obstáculos mais visíveis enfrentados pelos departamentos de TI de muitas organizações. Um sistema que tornou-se legado pode ser simplesmente definido como qualquer sistema que seja difícil e caro de manter.

Há todo um espectro de razões pelas quais isso poderia ser o caso, mas, essencialmente, é porque:
(A) Está sendo executado em uma plataforma cara (e muitas vezes obsoleta);
(B) É escrito em uma linguagem obsoleta;
(C) Não há mais ninguém na equipe que o compreenda.  

 Estas questões compartilham o mesmo resultado: um sistema legado não tem a agilidade que a maioria das empresas precisa para apoiar as mudanças nos seus processos, além de que está custando muito mais para manter.

 

 Motivadores de negócios para a modernização:  

• A rápida evolução das necessidades do consumidor e dos modelos de negócios
• Tarefas manuais caras e demoradas devido à sub-processos semi manuais – o processo global não é racionalizado.
• Incapacidade para adicionar interações ricas (baseadas na web) e módulos móveis para aplicações legadas.
• Os usuários não estão satisfeitos
• Novos padrões/regulamentos/notificações não podem ser implementados/suportados em tempo.
• Integração manual de processos
• Fusão e Aquisição – necessidade de integrar processos de negócios
• Definição e monitoramento de workflow/processo
• Alto custo de manutenção de sistemas legados reduzindo o orçamento disponível

 

Motivadores de Tecnologia:  

• Permitir o uso de Web Services
• Reutilização do código existente combinado com novos serviços/códigos
• Sincronização de dados entre legado e novas aplicações/processos
• Migração, substituição ou cenários mistos de plataforma e/ou banco de dados
• Conectividade de aplicações legadas e outras aplicações diretamente ou através de sistemas de mensagens (JMS, MS MQ e Websphere MQ); substituindo interfaces proprietárias com plataforma de integração escalável
• Construção de uma arquitetura SOA, incluindo aplicações legadas
• Manipulação de transações para processos que integram aplicações legadas

 

Opções com Legados

Tradicionalmente, há poucas opções quando uma organização procura lidar com um desafio do sistema legado. Geralmente, uma organização pode:

Substituí-lo: Criar um novo sistema que substitui a funcionalidade completa do sistema antigo. Este é a opção mais difícil, mais dispendiosa e arriscada, mas é a única que oferece uma solução de longo prazo e, possivelmente, fornece um sistema que seja ágil o suficiente para responder às novas necessidades do negócio. Questões a considerar incluem:
• Alto custo inicial de desenvolvimento;
• Risco muito elevado;
• Dificuldade para adquirir o comportamento do sistema legado;
• Risco de criação de um sistema legado de segunda geração;
• Possibilidade de criação de um novo sistema, mais ágil.

Envolvê-lo: Trata-se de envolver a aplicação do legado existente em interfaces mais modernas e atraentes. Essas interfaces permitem o uso de abordagem mais flexível de arquitetura orientada a serviços. Isso realmente não ajuda a tornar o sistema mais flexível e mais fácil de manter. Mas, contudo, permite maior acesso ao sistema legado por outros sistemas. Esta abordagem pode permitir que o sistema legado seja modularizado e, assim, parte dele pode ser substituído em uma base fragmentada. As considerações incluem:
• Custo inicial de pequeno porte;
• Baixo risco;
• Ainda é necessário manter os sistemas legados;
• Não há aumento de agilidade no sistema legado.

Viver com ele: Tendo em conta as possíveis repercussões das alternativas, esta é uma opção popular que não surpreende. Além do risco envolvido ser quase zero,  infelizmente isso não oferece nenhuma esperança para o alívio do problema do legado e fornece apenas estagnação. Com esta opção, as principais características são:
• Não há custo inicial;
• Não há redução no custo de manutenção ou na capacidade de aumentar as eficiências da operação;
• Não há aumento na agilidade.

 

Nesta situação, como o iBOLT tornaria a integração mais fácil?

Com o iBOLT você teria que usar simplesmente uma única ferramenta para se conectar às suas aplicações legadas, então Appley e seus colegas poderiam utilizar um conector do iBOLT for System i/AS400 para integrar rapidamente o AS400 e o sistema Yardi sem necessidade de qualquer codificação local. O iBOLT é uma plataforma de integração livre de código. Abaixo está uma imagem do iBOLT que mostra apenas uma coleção de componentes que servem a diferentes tecnologias.

Por exemplo, usando uma ferramenta para conectar de/para sua aplicações legadas para permitir compartilhamento de dados e processos com outras aplicações. Ou um produto que tem um suporte embutido para diferentes ambientes e plataformas e pode fornecer a ponte entre eles.

Aqui está um exemplo de como acessar os serviços do sistema System i – com recuperação de listas de objetos, valores do sistema, entradas do arquivo de spool, e arquivos do diretório IFS.    

iBOLT acessando System i

  

- Integração / Exposição dos elementos do System i – que podem chamar processos externos em qualquer outra plataforma de programas OS/400 RPG/CL/Cobol via API requisitada pelo iBOLT
- Função embutida de abrir o arquivo de consulta – que permite a seleção e classificação de registros no System i
- Runtime de gerenciamento de ambiente – com  acompanhamento do projeto em tempo real e o iBOLT pode ser usado para permitir que sistemas legados facilmente se conectem e consumam serviços recém-criados da web. O iBOLT trata automaticamente cada chamada e resposta de webservice de cada mensagem de acordo com o protocolo padrão SOAP e HTTP. Você pode efetivamente integrar aplicações legadas e aplicações baseadas na nuvem, incluindo as locais e as remotas.    

O que é mais prova de um bom futuro, do que você poder se concentrar no desenvolvimento de processos de negócio independente da tecnologia utilizada.Você, portanto, mantém todo o controle dos processos de negócios da sua empresa melhor do que qualquer fornecedor conseguiria.    

Para obter uma representação visual do iBOLT em ação, dê uma olhada no vídeo abaixo sobre o iBOLT e a integração SAP, mas lembre-se que poderia ser qualquer coisa, desde algo escrito em casa , até algo escrito em RPG.    

Publicado em Cloud Computing, Integração, iBOLT | Etiquetado , , , | Deixar um comentário »

Postagens Antigas »