ESTÁGIO CURRICULAR II DESENVOLVIMENTO DE ADAPTERS EM XML E MANUTENÇÃO DE APLICATIVOS

Simone Cristine Langer ESTÁGIO CURRICULAR II DESENVOLVIMENTO DE ADAPTERS EM XML E MANUTENÇÃO DE APLICATIVOS EMPRESA: Logistics Solutions Ltda SETOR: Eq. de Operações SHV Gás SUPERVISOR:Anderson Hoepers ORIENTADOR:Charles Christian Miers CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE CIÊNCIAS TECNOLÓGIAS - CCT UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC JOINVILLE SANTA CATARINA - BRASIL Agosto/2007

ii APROVADO EM.../.../... Professor Charles Christian Miers Mestre em: Ciência da Computação Professor Orientador Professor Débora Cabral Nazário Mestre em Ciências da Computação Professor Everton Luis Alves Espec. em Gestão Empresarial Anderson Hoepers Graduado em Comércio Eletrônico Pós-graduado em Logística Empresarial Supervisor da CONCEDENTE

iii Carimbo da Empresa UNIDADE CONCEDENTE Razão Social: Logistics Solutions Ltda CGC/MF: 03.346.454/0001-07 Endereço: Av. Santos Dumont, 935 2º andar Bairro: Santo Antônio CEP: 89218-105 Cidade: Joinville UF: SC Fone: 38028624 Atividade Principal : Software House Supervisor: Anderson Hoepers Cargo: Analista de Sistemas ESTAGIÁRIO Nome : Simone Cristine Langer Matrícula: 211220413 Endereço: R: Marcelino Krucheldorf, 188 Bairro: Iririú CEP: 89227-024 Cidade: Joinville UF: SC Fone: 3028-3407 Curso de : Tecnologia em Sistemas de Informação Título do Estágio: Período: 13/08/2007 a 24/09/2007 Carga horária:120 Hrs AVALIAÇÃO FINAL DO ESTÁGIO PELO CENTRO DE CIÊNCIAS TECNOLÓGICAS Representada pela avaliação do Processo de Estágio Estes campos serão preenchidos pelo professor da Disciplina, devido a avaliação ser do Processo e não somente do Relatório CONCEITO FINAL (Avaliação do Processo de Estágio) Excelente (9,1 a 10) Muito Bom (8,1 a 9,0) Bom (7,1 a 8,0) Regular (5,0 a 7,0) Reprovado (0,0 a 4,9) NOTA (Σ Processo) Rubrica do Professor da Disciplina Joinville / /

iv Nome do Estagiário : Simone Cristine Langer QUADRO I AVALIAÇÃO NOS ASPECTOS PROFISSIONAIS QUALIDADE DO TRABALHO: Considerando o possível. ENGENHOSIDADE: Capacidade de sugerir, projetar, executar modificações ou inovações. CONHECIMENTO: Demonstrado no desenvolvimento das atividades programadas. CUMPRIMENTO DAS TAREFAS: Considerar o volume de atividades dentro do padrão razoável. ESPÍRITO INQUISITIVO: Disposição demonstrada para aprender. INICIATIVA: No desenvolvimento das atividades. SOMA Pontos QUADRO II AVALIAÇÃO DOS ASPECTOS HUMANOS ASSIDUIDADE: Cumprimento do horário e ausência de faltas. DISCIPLINA: Observância das normas internas da Empresa. SOCIABILIDADE: Facilidade de se integrar com os outros no ambiente de trabalho. COOPERAÇÃO: Disposição para cooperar com os demais para atender as atividades. SENSO DE RESPONSABILIDADE: Zelo pelo material, equipamentos e bens da empresa. SOMA Pontos PONTUAÇÃO PARA O QUADRO I E II Sofrível - 1 ponto, Regular - 2 pontos, Bom - 3 pontos, Muito Bom - 4 pontos, Excelente - 5 pontos LIMITES PARA CONCEITUAÇÃO AVALIAÇÃO FINAL Pontos De 57 a 101 - SOFRÍVEL SOMA do Quadro I multiplicada por 7 De 102 a 147 - REGULAR SOMA do Quadro II multiplicada por 3 De 148 a 194 - BOM SOMA TOTAL De 195 a 240 - MUITO BOM De 241 a 285 - EXCELENTE Nome da Empresa: Logistics Solutions Ltda Representada pelo Supervisor: Anderson Hoepers

v CONCEITO CONFORME SOMA TOTAL Rubrica do Supervisor da Empresa Local: Data : Carimbo da Empresa

vi UDESC UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS - FEJ PLANO DE ESTÁGIO CURRICULAR II ESTAGIÁRIO Nome: Simone Cristine Langer Matrícula: 211220413 Endereço (Em Jlle): R: Marcelino Krucheldorf, 188 Bairro: Iririú CEP: 89227-024 Cidade: Joinville UF: SC Fone: 30283407 Endereço (Local estágio): Av. Santos Dumont,935 2º andar Bairro: Santo Antônio CEP: 89218-105 Cidade: Joinville UF: SC Fone: 3802-8785 Regularmente matriculado no semestre: 5º Curso: Tec. em Sistemas de Informação Formatura (prevista) Semestre/Ano:01/2008 UNIDADE CONCEDENTE Razão Social: Logistics Solutions Ltda CGC/MF: 03.346.454/0001-07 Endereço: Av. Santos Dumont, 935 2º andar Bairro: Santo Antônio CEP: 89218-105 Cidade: Joinville UF: SC Fone: 38028624 Atividade Principal : Software House Supervisor: Anderson Hoepers Cargo: Analista de Sistemas DADOS DO ESTÁGIO Área de atuação: Materiais Departamento de atuação: Eq. de Operações SHV Gás Fone: 3802-8785 Ramal: 8785 Horário do estágio: 08:00 ao 12:00 Total de horas: 120 Horas Período: 13/08/2007 à 24/09/2007 Nome do Professor Orientador: Charles Christian Miers Disciplina(s) simultânea(s) com o estágio Quantas: 6 disciplinas Quais: Gerência de Projetos (GPR) Pesquisa Operacional (PES-SI) Sociologia das Organizações (SOR) Visão de Marketing (TES-05) Fund. De Interface Humano-Computador (TES-06) Análise e Projeto de Sistemas Avançados (TES-12)

vii OBJETIVO GERAL Desenvolver programas em XML (adapters) para efetuar a integração do módulo EAI do EMS2 com módulos de outras empresas. Manutenção de programas específicos do cliente SHV GÁS, para correção ou melhoria de funcionalidade. ATIVIDADES OBJETIVO ESPECÍFICO HORAS Desenvolvimento de Adapters Desenvolvimento de programas em XML responsável pela comunicação 20 entre o ERP e os diversos módulos de outras empresas que o cliente SHV Gás possui, para o envio e recebimento dos dados (adapters). Manutenções de específicos Manutenção de específicos sendo está de correção ou de melhoria de funcionalidade. 80 Documentações das Atividades Documentar as atividades exercidas durante o período de estágio 20 Rubrica do Professor Orientador Rubrica do Coordenador de Estágios Rubrica do Supervisor da Empresa Data: Data: Data: Carimbo da Empresa Prof.Charles Christian Miers Prof. César Malutta Anderson Hoepers

CRONOGRAMA FÍSICO E REAL PERÍODO (04horas) ATIVIDADES P R 0 1 0 2 0 3 0 4 05 0 6 0 7 0 8 0 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 Desenvolvimento de Adapters P R Manutenções de específicos P R Documentações das Atividades P R P R P R P R P R P R P R P R P R P R

!"#$%$ & $ '& ( $# )*+,$ - $ +"%$./& "01!0%$% %&!#$%& % $"#$ $#$ 0"$2!"#$%$,& &3!!& 40,!&" 5&!6 $3 $ * #$7 &!'+0"#2 "$ 3& 7$ %$ 0 "89 :9;<;2 % =>?(?>>2 '+,$7"#$%$,& * #& "89 @>9;<>2 % @?=@?@(2 #"%& 7 10!#$ &"1A"0& "89?(==;2 +B,0*$%& 7 0C 0& 30*0$, "89 %??9 #9 8 %!"1&,1 C!#C'0&D B 0'$#E 0& /& &B 0'$#E 0& #9 (8 %!"1&,1 C $#010%$%! %"# &%!+$,0"F$ % 3& 7$./&9 #9-8,$B& $ C &' $7$ % #010%$%! $! *+7 0%&,& 2 7 *&"3& 70%$% *&7 $! %0!*0,0"$! *+!$%$!,& 7!7&2!0#$%&! &! F& C 0&! %&B 0'$.G! %& *&7 $?9 #9 ;8!#C'0&! C %!"1&,10%& "$ $ 7 "& )&%& %?? $??9 H 8!# )&%& &% C! & &'$%& 7%0$"# 610& "#"%07"#& "# $! $ #!9 H (8 $"#& $ *&7& & &% /& $ I+$,I+ 7&7"#& %$ & # 70"$%& &!#C'0&2 7%0$"# *&7+"0*$./&!* 0#$9 #9 J8,$! $0! *) &*$! 1$"#$'"! #6*"0*$! $%70"0!# $#01$!2 $ %!0'"$ C *&7& + 10!& "# "& %!#C'0&! $1$,0$%& & "F& #9 :8 %*,$ $ *&"*& %$ *&7 $! "& 7$! 0"# "$! %$ 2 *&"%+K0! %"# &%$ 6#0*$ &30!!0&"$,!+B7#! $ $*&7$"F$7"#& $1$,0$./& %!+ %!7"F& $ &10#$7"#&9 #9 >8!&B 0'$ $ *+7 030,7"# $ &' $7$./& %!#C'0&9 #9 @8!&"% C,$! %$! %$"&! *&"!IL"#! %$ 0"&B! 1M"*0$ %$! "& 7$! 0"# "$! %$ 9 #9 <8! *&7 &7# $,$B& $,$#E 0&!&B &!#C'0& $,0K$%& $!"#$"%&& N $# $16! %!+ + 10!& 2 N "01!0%$% $# $16! %& && %"$%& %!#C'0&!!*#01&9 #9 =8!!&"!$B0,0K$ C & %!!$!,$#01$! $ $#010%$%! O# $! 07&!#$! $& 9

x #9 8 "/& # C $ $ I+$0!I+ 30#&!2 1)"*+,& 7 '$#)*0& *&7 $ 2 30*$"%& $I+,!'+ $%& *&"# $ $*0%"#!!!&$0! %+ $"# &!#C'0&,$ $E,0* "89 %$ &7$"F0$ #9 (8 *B C +7$ B&,!$ "& 1$,& % 9 #9 # -8 0*$ 307$%& &!"# 7 - # A! 10$! % 0'+$, #& 9 5&0"10,2 % % (==J9 D 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 ( D 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 - D 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999

xi Ao meu noivo Ronaldo France da Silva A todos os meus amigos e colegas Aos meus familiares

xii AGRADECIMENTOS Muitas pessoas e empresas tornaram-se merecedoras do nosso reconhecimento, pelo muito que colaboraram para a realização deste trabalho, dentre elas destacam-se: Luiz Carlos Knupp Pinheiro Hederson Bisewski Anderson Hoepers Michel Schroeder Rubia Daniele Pires De Oliveira Arthur Fernando Yendo Felipe Grutzmacher SHV Gás Datasul Logística

xiii SUMÁRIO RUBRICA DO PROFESSOR DA DISCIPLINA...III QUADRO I... IV QUADRO II...IV PONTUAÇÃO PARA O QUADRO I E II...IV HORAS... VII LISTA DE FIGURAS...XV LISTA DE TABELAS... XVI LISTA DE TABELAS... XVI RESUMO... XVII INTRODUÇÃO... 1 1.1. OBJETIVOS... 1 1.1.1. GERAL... 2 1.1.2. ESPECÍFICOS... 2 1.1.3. JUSTIFICATIVA... 2 1.2. ORGANIZAÇÃO DO ESTUDO... 3 2. A EMPRESA... 4 2.1. HISTÓRICO... 4 2.2. PRINCIPAIS PRODUTOS... 4 2.3. PRINCIPAIS CLIENTES... 5 2.4. CONSIDERAÇÕES GERAIS... 6 3. FERRAMENTAS INTERNAS... 7 3.1. MCS... 7 3.2. ROUNDTABLE... 8 3.3. XMLSPY... 11 3.4. WIZARDADAPTERS V0.08E... 12 4.1. ESTUDO LINGUAGEM XML... 15 4.1.1 CARACTERÍSTICAS DO XML... 16 4.1.2 ESTRUTURA DO DOCUMENTO XML... 16 4.1.3 BENEFÍCIOS DA UTILIZAÇÃO DO XML... 17 4.2. EAI ENTERPRISE APPLICATION INTEGRATION... 18 4.3. MONTAGEM DE AMBIENTE... 20 4.3.1 MENSAGEM PADRÃO DATASUL... 20 4.3.2 CONTROL BROKER... 20 4.3.3 ESTRUTURA DE DIRETÓRIOS... 21 4.3.4 ARQUIVOS DE CONFIGURAÇÃO... 22 4.3.5 VALIDAÇÃO E TRANSFORMAÇÃO... 25 4.3.6 CONFIGURAÇÃO PASSO A PASSO... 26 4.4 DESENVOLVIMENTOS DE ADAPTERS... 27

xiv 4.5. MANUTEÇÃO DE APLICATIVOS... 34 4.5.1. SOLUÇÃO... 35 4.5.2. LIBERAÇÃO E ENCERRAMENTO... 35 5. CONSIDERAÇÕES FINAIS... 36 5.1. PRINCIPAIS DIFICULDADES... 36 5.2. DISCIPLINAS QUE AUXILIARAM NA REALIZAÇÃO DO ESTÁGIO... 36 5.2.1. ICC - INTRODUÇÃO A CIÊNCIA DA COMPUTAÇÃO... 36 5.2.2. LPG I - LINGUAGEM DE PROGRAMAÇÃO I... 37 5.2.3. LPG II - LINGUAGEM DE PROGRAMAÇÃO II... 37 5.2.4. ANA - INTRODUÇÃO À ANÁLISE... 37 5.2.5. SOFT - ENGENHARIA DE SOFTWARE... 38 5.2.6. BAN - BANCO DE DADOS... 38 ANEXOS... 39 ANEXO B: DOCUMENTAÇÃO DA ATIVIDADE DE ENVIO DO USUÁRIO X ESTABELECIMENTO AO GPS... 40 ANEXO C: DOCUMENTAÇÃO DA ATIVIDADE DE ENVIO DO PLANEJAMENTO DAS VIAGENS AO CORE... 41 ANEXO D: DOCUMENTAÇÃO ATIVIDADE DE MANUTENÇÃO FO1589981... 42 ANEXO F: DOCUMENTAÇÃO ATIVIDADE DE MANUTENÇÃO FO1534011... 44 GLOSSÁRIO... 47 BIBLIOGRÁFIA... 49

xv LISTA DE FIGURAS Figura 1- Menu do MCS... 7 Figura 2 Tela de atualização que lista as tarefas... 8 Figura 3 Tela de login do usuário no RoundTable... 10 Figura 4 Tela do RoundTable... 11 Figura 5 XMLSPY... 12 Figura 6 ferramenta para Gerar o adapter tela inicial.... 13 Figura 7 Opções de adapters... 13 Figura 8 Tela para informar dados... 14 Figura 9 - Exemplo de código XML... 15 Figura 10 - Exemplo da Estrutura do XML... 17 Figura 11 - Arquitetura de Integração EAI... 18 Figura 12 - Visualização de código XML no XMLSPY... 19 Figura 13 - XML Schema do arquivo InstalledApplications.xml... 23 Figura 14 - XML Schema do arquivo TransactionSubscription.xml... 23 Figura 15 - XML Schema do arquivo ProcessingInfo.xml... 24 Figura 16 XML Schema do arquivo MessageConstants.xml... 25 Figura 17 Código do Adapters AXSPLD009... 27 Figura 18 XML Schema Frota... 28 Figura 19 Programa de Cadastro de Frotas... 28 Figura 20 Adapter AXSPLD008... 29 Figura 21 XML Schema Usuário... 30 Figura 22 Programa Relacionamento Grupos X Usuário... 30 Figura 23 Adapters AXRPLD010... 31 Figura 24 XML Schema de Viagem dados enviados... 32 Figura 25 XML Schema da Viagem dos dados retornados parte I... 32 Figura 26 - XML Schema da Viagem dos dados retornados parte II... 33 Figura 27 PLD0032G programa que executa o adapter... 34

LISTA DE TABELAS xvi

xvii RESUMO Este trabalho tem por objetivo documentar o estágio realizado na empresa Datasul Logística, tendo como base algumas atividades como desenvolvimento e manutenção em XML, manutenção de programas específicos e a documentação das atividades exercidas. O desenvolvimento em XML tem por finalidade para efetuar a integração com os diversos sistemas que a empresa SHV Gás possuí com o EMS. A manutenção de específicos do cliente SHV Gás, são efetuadas utilizando os padrões de programação, templates Datasul e as metodologias definidas nas propostas de manutenção dos aplicativos, de forma a atender as necessidades do cliente e melhorar continuamente as funções especificadas, esses padrões e metodologias estão especificados nos manuais da empresa. Por fim será feita a documentação das atividades executas durante o período de estágio a fim de apresentar a causa que levou a efetuar a manutenção ou até mesmo o desenvolvimento de algum aplicativo.

INTRODUÇÃO Neste relatório serão apresentadas as tarefas executas as ferramentas utilizadas e também será apresentado o histórico da empresa Datasul Logística onde foi feito o estágio. Todas as atividades desenvolvidas serão documentadas assim como as ferramentas utilizadas. A empresa onde ocorreu o estágio é voltada para área de logística, foi constituída em 1999 com a divisão da empresa da Datasul em franquias, ela possui diversos módulos mas hoje ela possui como investimento próprio quatro módulo que são Avaliação de Fornecedores, Aprovação eletrônica, Portal CRM, Otimização de Estoque. As atividades exercidas foram o desenvolvimento dos novos adapters e a manutenção de aplicativos com a utilização da linguagem de programação Progress. No desenvolvimento dos adapters foram utilizadas as ferramentas XMLSPY e o Gerador de adapters WizardAdapters v0.08e. Para efetuar a manutenção dos aplicativos do produto Datasul foi utilizando o Roundtable e para efetuar os testes foi utilizada a própria base do EMS2. 1.1. OBJETIVOS No início do estágio foram planejadas algumas atividades para atingir a carga horária exigida para o estágio um total de cento e vinte horas, está atividades são desde os desenvolvimentos de programas em XML os adapters, a manutenção de específicos e a documentação das atividades que serão exercidas.

2 1.1.1. GERAL Desenvolver programas em XML (adapters) para efetuar a integração do módulo EAI do EMS2 com módulos de outras empresas, manutenção de programas específicos do cliente SHV GÁS, para correção ou melhoria de funcionalidade. 1.1.2. ESPECÍFICOS Para que seja possível alcançar o objetivo principal foram definidas algumas atividades como o desenvolvimento de programas em XML responsável pela comunicação entre o ERP e os diversos módulos de outras empresas que o cliente SHV Gás possui, para o envio e recebimento dos dados (adapters). A manutenção de específicos sendo está de correção ou de melhoria de funcionalidade. Assim que todas as atividades estejam completas será feita a documentação das atividades exercidas durante o período de estágio. 1.1.3. JUSTIFICATIVA Com a necessidade que os clientes possuem em ter módulos que atendam as suas necessidades nem sempre eles utilizam um sistema completo de apenas um fornecedor vendo isto se tornou necessário fazer a integração dos módulos de diferentes sistemas com o EMS, para que o cliente possua as mesmas informações em todos os módulos dos diversos sistemas. Esta integração é feita pelo módulo EAI 1 utilizando XML (extensible Markup Language Linguagem de Marcação Extensível), para isso são desenvolvidos alguns adapters que efetuarão o envio e o recebimento das mensagens para efetuar a comunicação entre os módulos. 1 EAI Enterprise Application integration, é um banco de dados que armazena as mensagens que são enviadas e recebidas e tem o objetivo de integrar os aplicativos de diversos sistemas com o produto Datasul.

3 Alguns aplicativos necessitam de manutenção corretiva ou de melhoria, estas melhorias podem ser devido a novas técnicas no mercado ou até mesmo decorrentes de novas leis, assim os aplicativos devem estar atendendo todas as normas, para que não tragam nenhum prejuízo ao cliente. A manutenção corretiva ocorre quando algum erro foi encontrado em testes ou foi feita uma alteração em um programa que acabou impactando em tantas outras funcionalidades, desta forma é aberta uma ficha de ocorrência conhecida como FO 2 para que seja registrado o erro e feita à alteração para resolver a causa. 1.2. ORGANIZAÇÃO DO ESTUDO A organização do estudo estará dividida da seguinte maneira, apresentação dos objetivos gerais e específicos explicando o que gerou a necessidade do estágio e as atividades que estão sendo planejadas para a sua execução. Será feito uma abordagem referente ao histórico da empresa onde ocorreu o estágio apresentando o seu faturamento inicial, os produtos que ela possuí e outras informações. Será feita a documentação das atividades e ferramentas utilizadas para a sua execução detalhando assim as tarefas. Nas considerações finais será descrito as dificuldades encontradas, as disciplinas que mais colaboraram para o sucesso do estágio. Ao final do relatório se encontra o glossário dos principais termos utilizados neste relatório e as bibliografias. 2 FO ficha de ocorrência

2. A EMPRESA Neste momento será apresentado um breve histórico da empresa apresentado quando ela foi fundada, quantidade de colaboradores que ela contava quando foi constituída e o seu faturamento. Serão citados os principais produtos onde se divide em alguns módulos, os principais clientes. Ao final da deste capitulo será apresentado os principais benefícios que são oferecidos, será apresentada a missão e a visão da empresa. 2.1. HISTÓRICO A Logística foi constituída em outubro de 1999 (DATASUL LOGÍSTICA, 2003), com a divisão da empresa da Datasul em franquias onde junto com a Logística nasceram mais quatro franquias a manufatura, tecnologia, HR, BI. No inicio a Logística contava com 92 colaboradores, (DATASUL LOGÍSTICA, 2003) os principais produtos que tinham eram: compras, investimentos, contratos de compras, controle de qualidade, recebimento, previsão de vendas, cotações, pedidos e naquele ano obteve um faturamento de R$ 6.540.006,00. 2.2. PRINCIPAIS PRODUTOS Os principais produtos da Logística estão divididos em diversos módulos são eles (DATASUL LOGÍSTICA, 2003): Controle de Contratos; Compras Controle de Qualidade; Estoque; Importação; Investimentos;

5 Recebimento; Administração de Cotas; Administração de Preço de Venda; Controle de Fretes; Cotação de Vendas; Descontos e Bonificação; Exportação; Faturamento; Obrigações Fiscais; Pedidos; Previsões de Vendas; Sales Force Automation; WMS 3 e DrawBack 4. Como investimento próprio (DATASUL LOGÍSTICA, 2003) a empresa possui mais 4 módulos: Avaliação de Fornecedores; Aprovação eletrônica; Portal CRM 5 e Otimização de Estoque. 2.3. PRINCIPAIS CLIENTES Os principais clientes (DATASUL S.A. 6, 2007) da empresa são: PPG Industries; Duas Rodas; 3 WMS Modúlo de gerencimanto de armazém 4 DrawBack Pertence ao módulo de exportação do EMS2 5 CRM - Customer Relationship Management ou Gestão de Relacionamento com Clientes. Software de gestão que possibilita maior eficiência no processo de gestão de clientes

6 Conexel; Handle; Tortuga; SHV Gás; Banrisul; Grendene; Vicunha; Bauducco e Aethra. 2.4. CONSIDERAÇÕES GERAIS Até agosto de 2007 a Logística contava com 238 colaboradores, oferece vários benefícios um deles Bolsa de estudos, tanto para Ensino Superior, como Pós-graduação e idiomas. Tem como visão Ser referência em Conhecimento nas áreas de Logística e CRM aplicando soluções inteligentes de Tecnologia da Informação, de forma consistente e contínua. Este ano a Logística (DATASUL LOGÍSTICA-1,2007) tem como objetivo ser reconhecida como parceira no network Datasul, para atuação conjunta em projetos nas áreas de logística e CRM 6. Obter 50% da receita de serviços, oriunda da participação em projetos de implementação, com serviços de maior valor agregado para os clientes. 6 CRM - Customer Relationship Management - Gerenciamennto do relacionamento com cliente.

3. FERRAMENTAS INTERNAS As ferramentas que são utilizadas para os desenvolvimentos e as manutenções são o MCS, o RoundTable, o MXLSPY e WizardAdapters. O MCS é a ferramenta onde é possível efetuar o gerenciamento de atividades tanto para o desenvolvimento quanto para a manutenção, o Roundtable que controla as versões dos programas e registram os usuários que efetuam as alterações, o XMLSPY é onde são criados os schemas do XML e WizardAdapters v0.08e que é uma ferramenta onde são colocados alguns dados e com esses dados são criados os adapters. Para que fosse possível utilizar estás ferramentas foi necessário fazer alguns treinamentos, este treinamentos se encontram no Universidade Datasul (DATASUL 8, 2007). 3.1. MCS O MCS (Management Control System Sistema de Controle de Manutenção) corresponde a um aplicativo que coloca à disposição o controle de tarefas, atividades e ordens de serviço de suporte, manutenção e desenvolvimento que serão enviadas ao cliente na figura 1 é apresentado o menu do MCS. Quando detectada uma eventual irregularidade, a tarefa em questão é devolvida ao programador responsável, gerando então o retrabalho. Caso contrário, o MCS permite que se encerre a tarefa. Figura 1- Menu do MCS.

8 O MCS (DATASUL 8,2007) é também uma ferramenta que permite o gerenciamento de tarefas individuais de cada programador apresentado na figura 2 a tela de atualização de tarefas. Ao terminar a alteração de um programa, por exemplo, devese realizar a chamada liberação especial para auditoria, pela qual os auditores têm acesso aos programas alterados e podem testá-los. Figura 2 Tela de atualização que lista as tarefas. 3.2. ROUNDTABLE O RoundTable (DATASUL 8,2007) apresentado na figura 3, é uma ferramenta de administração de códigos-fonte. Através do controle de objetos (programas) e liberações de bases de dados, permissões de alterações e criação de programas são distribuídas aos desenvolvedores.

9 O principal processo do RoundTable é a realização de um check-out, ou seja, o "travamento" de um objeto com o programador responsável por período indeterminado (ou até que suas alterações sejam finalizadas). Durante este espaço de tempo o programa, denominado objeto preso, não se encontra disponível para outras modificações. Outro processo presente no RoundTable é o check-in. Por meio dele, um objeto restrito é colocado novamente à disposição de todos os programadores. O uso incorreto do check-in pode causar sérios problemas nos programas, pois alterações não testadas pela equipe de qualidade podem ser expedidas. Recomenda-se que se utilize esta opção apenas quando o objeto em questão não for alterado. Após a conclusão das alterações de programas, é necessário que se libere estas mudanças para backup. Essa é uma etapa fundamental do desenvolvimento, pois através deste processo, os objetos são enviados para um diretório compartilhado na rede, podendo gerar um pacote compilado com os arquivos deste diretório.

10 Figura 3 Tela de login do usuário no RoundTable. Na figura 4 é apresentado uma tarefa onde tem vários objetos que estão preso com um usuário para fazer as alterações e outras usuários só tem acesso a estes objetos somente para leitura.

11 Figura 4 Tela do RoundTable. 3.3. XMLSPY Está ferramenta será utilizada para o desenvolvimento em XML, o XMLSPY 7. Ele é o editor para o desenvolvimento padrão em XML, inclusive para modelagem, edição e depuração de erros. O XMLSpy permite ao desenvolvedor criar as mais avançadas tecnologias em XML, mas o mesmo é flexível o suficiente para permitir o uso das visões e opções que mais atendem às necessidades de negócio e trabalho. 7 XMLSPY - disponível para download no site http://www.altova.com.

12 Figura 5 XMLSPY. Na figura 5 é apresentado o schema do adapter de frota como exemplo, apresentado no modo gráfico, onde a Frota enviará vários dados como serial do GPS, a placa do veículo, descrição do veículo, situação do envio, filial, UF, grupo. 3.4. WizardAdapters v0.08e O WizardAdapters v0.08e é o gerador de adapters desenvolvido pela franquia de finanças da Datasul, está ferramenta facilita a criação do adapter, pois basta você criar o Schema no XMLSPY e completar alguns dados que são solicitados conforme as figuras 6, 7 e 8, ele gerará o adapter com o código padrão como por exemplo a criação do nós, o programador não vai necessitar se preocupar com a programação básica.

13 Figura 6 ferramenta para Gerar o adapter tela inicial. Na figura 6 é apresentada a tela incial do adapter e vem com a opção nova transação marcada que deverá então ser informado o Schema criado no XMLSPY. Figura 7 Opções de adapters. Na figura 7 é onde é será escolhida a opção caso o adapter seja de envio ou de recebimento.

14 Figura 8 Tela para informar dados. Na figura 8 é onde são informados os dados solicitados para criação do adapter, com esses dados o programa que irá ser gerado saberá qual transação ele utilizará a versão do produto, módulo e a ações que deverá fazer como pro exemplo uma consulta, inclusão ou eliminação de dados. 3.5. Considerações Gerais Foi objetivo deste capítulo mostrar todas a ferramentas que são utilizadas para o desenvolvimento e manutenção, para que durante o capítulo de desenvolvimento seja possível somente destacar qual a ferramenta foi utilizada para uma determinada tarefa.

15 4. DESENVOLVIMENTO No desenvolvimento serão documentadas as atividades executadas durante o período de estágio. Para desenvolver está atividades foi necessário adquirir algumas noções sobre as ferramentas utilizadas e isto ocorreu através de treinamento pela Universidade Datasul (DATASUL 8, 2007), também foi necessário adquirir algum conhecimento referente o EAI dos tipos de transação e o porque utiliza-lo, aprender um pouco sobre XML como as características da linguagem a sua estrutura que também serão documentadas. 4.1. ESTUDO LINGUAGEM XML É uma linguagem de marcação de dados (meta-markup language) que provê um formato para descrever dados estruturados. Isso facilita declarações mais precisas do conteúdo e resultados mais significativos de busca através de múltiplas plataformas. O XML também vai permitir o surgimento de uma nova geração de aplicações de manipulação e visualização de dados via internet. É, assim, um padrão aberto que define um conjunto de regras para a construção de documentos e que tem como foco a estruturação das informações, não a apresentação do documento para o qual existem tecnologias auxiliares. O XML tem sido muito utilizado na integração de aplicativos por apresentar uma maneira muito flexível e pouco ambígua de representar informações. Figura 9 - Exemplo de código XML.

16 Na figura 9 há um exemplo de XML, no qual a mensagem contém as informações de código de um cliente, seu nome, endereço e sexo. Assim, fica claro que o XML é uma linguagem estruturada e extremamente simples de ser entendida. No entanto, como no caso de qualquer outra linguagem de programação, é preciso conhecê-la mais profundamente para que seja possível a sua utilização. Assim, serão analisadas agora as principais características do XML, a sua estrutura, os benefícios da sua utilização e a ferramenta que será utilizada para o desenvolvimento do XML 4.1.1 CARACTERÍSTICAS DO XML O XML (DATASUL S.A. 3, 2003) provê um padrão que pode codificar o conteúdo, as semânticas e esquematizações, para uma grande variedade de aplicações, desde as mais simples, como um pequeno documento, até os mais complexos, como todos os links entre informações e pessoas na internet. Além disso, outra característica importante é que ele permite que os dados recebidos por um cliente sejam manipulados, editados e visualizados sem a necessidade de acionar novamente o servidor, reduzindo a sobrecarga, a computação e a requisição de banda. A mais importante característica do XML, entretanto, se resume em separar a interface com o usuário (apresentação), dos dados estruturados, uma vez que ele define o conteúdo do documento. Essa separação dos dados da apresentação permite, portanto, a integração de dados de diversas fontes. Informações de consumidores, compras, ordens de compra, resultados de busca, pagamentos, catálogos, podem ser convertidas para XML, permitindo que os dados sejam trocados on-line tão facilmente como as páginas HTML mostram dados (DATASUL S.A. 3, 2003). 4.1.2 ESTRUTURA DO DOCUMENTO XML Um documento XML (DATASUL S.A. 3, 2003) é semelhante a uma árvore rotulada na qual um nó (TAG) externo consiste de dados de caracteres (uma seqüência de texto), instruções de processamento, um comentário (nunca acompanhado por

17 semântica), declaração de entidades e nós DTD (Document Type Declaration). Já os nós internos são elementos rotulados com um nome ou um conjunto de atributos. Figura 10 - Exemplo da Estrutura do XML. Na figura 10 é apresentado um exemplo da estrutura do XML, com as TAG s internas e raiz, onde o nó raiz é Receita e os nós filhos ou internos são os Títulos, Autor e Data. 4.1.3 BENEFÍCIOS DA UTILIZAÇÃO DO XML Para o desenvolvimento do XML será utiliza a ferramenta XMLSPY que já foi descrita no item 3.3. O XML tem como objetivo trazer flexibilidade e poder às aplicações WEB. Dentre os benefícios para desenvolvedores e usuários pode-se mencionar (DATASUL 3, 2003): Buscas mais eficientes, pois os dados em XML podem ser unicamente etiquetados ; Desenvolvimento de aplicações flexíveis para WEB; Integrações de dados de fontes diferentes; Computação e manipulações locais; Atualizações de forma granular, evitando que uma pequena modificação no conjunto de dados implique na busca do documento inteiro novamente;

18 Fácil distribuição na WEB; Escalabilidade e Compressão dos documentos. O XML será utilizado para efetuar a integração do produto EMS2 com outros sistemas de qualquer empresa, neste momento está sendo utilizado para fazer integração com o GPS está integração só é possível com a utilização do módulo de integração EAI. 4.2. EAI ENTERPRISE APPLICATION INTEGRATION O EAI têm o desafio de conseguir integrar as aplicações entre fornecedores e clientes, em especial devido à grande complexidade dos ambientes (diversos sistemas operacionais, bancos de dados, linguagens, aplicações totalmente diferentes e fornecedores distintos) dos seus clientes (DATASUL S.A. 9, 2005). A Datasul viu a necessidade de fornecer aos seus clientes um aplicativo que realizasse também integrações com soluções de outras empresas, ou até mesmo de órgãos governamentais. Com isso em mente, foi incluído no EMS Datasul o produto EAI ((DATASUL S.A. 9, 2005)), com o objetivo de combinar métodos e tecnologias para a troca de informações de negócios em formatos e contextos que cada uma delas entende. Com isso, e com a tendência do mercado de utilização de integrações fazendo uso da tecnologia EAI, ela foi adotada como padrão de integração para todo o ERP Datasul conforme apresentado na figura 11. Figura 11 - Arquitetura de Integração EAI.

19 Conforme a figura 11 mostra, os produtos Datasul EMS 2, EMS 5 e HR (que são sistemas desenvolvidos na linguagem Progress que geram transações, bem como processam as transações recebidas) utilizam um adapter para interpretar ou criar as mensagens XML. Após tendo feito isso, as mensagens passam pelo Control Broker 8, que é responsável por receber a mensagem XML e transportar (numa espécie de roteamento) para os destinos (adapters). A partir do Control Broker, a mensagem segue para o Datasul Service Bus, que tem por objetivo fazer a integração de aplicativos, sejam eles Datasul ou não, focando assim nas transações. Já na parte de B2B, ou seja, integração focada no documento, a mensagem é integrada com outros parceiros. Conforme a figura 12 mostra, o XMLSPY já descrito no tópico 3.3 ajuda a visualizar o código de maneira mais estruturada, facilitando também a busca dos campos e a sua inclusão, já que não há necessidade de incluir um novo campo (ou TAG). Figura 12 - Visualização de código XML no XMLSPY. 8 Contro.Broker é o mecanismo utilizado para fazer a distribuição da mensagem (DATASUL 9,2005)

20 Na figura 12 é apresentado um código utilizando o XMLSPY para visualização, onde na caixa Details que aparece no lado direito, você pode colocar as características do campo que você está incluindo ou alterando, está características vão desde o fromato do campo até informar se é um campo obrigatório. Assim, o XMLSPY realmente se mostrou uma ótima ferramenta para o desenvolvimento da parte do projeto em XML. 4.3. MONTAGEM DE AMBIENTE Neste item são apresentados os vários componentes que formam o ambiente de integração EAI do produto Datasul e como é feito o relacionamento entre eles. Serão apresentados desde conceitos padrão da Datasul até a estrutura de diretórios necessária para o desenvolvimento e teste da integração. Para que a integração ocorra de forma correta é necessário seguir algumas tarefas para configuração do ambiente e estas tarefas vão ser descritas de forma a dar uma noção de como ocorre durante o desenvolvimento. 4.3.1 MENSAGEM PADRÃO DATASUL Os produtos da Datasul estão preparados para manipular mensagens que estejam dentro do padrão por ela definido. Tal padrão (DATASUL S.A. 1, 2003) possui informações que não estão armazenadas nas bases de dados. Ele também possui elementos opcionais, cujo uso é definido no ambiente do cliente. Além disso, existem certos processamentos que podem ou não serem realizados na mensagem, e a definição desta questão também só podem ser feita no ambiente do cliente. Todos estes pontos são definidos através de arquivos de configuração que estão no formato XML. 4.3.2 CONTROL BROKER O Control Broker (DATASUL 9, 2005) é o componente responsável por fazer a distribuição das mensagens que circulam entre os sistemas escritos em Progress. A

21 integração entre tais sistemas é realizada de maneira síncrona, ou seja, o programa que gera uma mensagem interrompe a sua execução e aguarda que a mesma seja entregue e processada nos sistemas destino, continuando seu trabalho apenas depois de receber uma resposta deles. Se houver a necessidade de integrar estes sistemas com outros não Progress, é utilizado então um dispositivo assíncrono que dê suporte a isso. Quando são utilizados esses tipos de mecanismos, um programa que gera uma mensagem simplesmente continua a sua execução, vão esperando qualquer retorno dos sistemas destino. Cabe ao dispositivo assíncrono (comumente chamado Message Broker), portanto, oferecer recursos para o gerenciamento de problemas nos sistemas de destino. Para realizar o roteamento das mensagens, o Control Broker (DATASUL 9, 2005) se apóia em arquivos de configuração. Para cada tipo de transação ele monta uma lista dos programas que devem ser executados e para os quais as mensagens daquela espécie devem ser passadas. Sendo assim, todo aplicativo que pretenda receber as transações de um determinado tipo deve indicar o programa a ser executado. 4.3.3 ESTRUTURA DE DIRETÓRIOS Cada produto da Datasul possui em seu diretório raiz alguns subdiretórios que são utilizados no processo de integração. A seguir são listados cada um deles e a sua descrição (DATASUL 9,2005): adapters/xml: A pasta adapters possui um subdiretório chamado XML onde estão localizados os programas que fazem a geração e interpretação das mensagens XML de integração (DATASUL 9,2005). xmlconf: Esta pasta contém a maioria dos arquivos de configuração do produto que controlam o processo de integração. Ela possui um subdiretório para cada aplicativo aonde são feitas algumas configurações específicas deles (DATASUL 9,2005). xmljserv: Esta pasta contém os programas que compõem os serviços de validação e transformação e os arquivos que os configuram (DATASUL 9,2005). xmllog: Nos subdiretórios desta pasta são gerados os arquivos de log de integração para cada aplicativo do produto. Caso esta pasta não seja encontrada,

22 será automaticamente criada no diretório temporário da sessão em execução (DATASUL 9,2005). xmlschema: Esta pasta possui um subdiretório por aplicativo, aonde são guardados os XML Schemas das transações que são de responsabilidade daquele aplicativo (DATASUL 9,2005). xmltransf: Nesta pasta ficam armazenados todos os arquivos de transformação (XSL) (DATASUL 9,2005). xmlutp: Esta pasta contém o Control Broker e outros utilitários auxiliares (DATASUL 9,2005). Todos os diretórios comentados são necessário para a integração do EAI com os outros sistemas, pois se alguns dos objetos estiverem fora desta estrutura de diretórios eles não serão encontrados e será apresentado vários erros. Por exemplo, no diretório adapters/xml é onde é colocado os adapters que vão gerar as mensagens com os dados enviados ou recebidos. No diretório xmlconf é onde eu vou assinar a transação que será executada sem este diretório, o sistema não encontrará o Schema que será executado. No xmljserv é onde é configurado os serviços de transações. No xmllog é onde é gerado o log, quando feito o envio de dados de forma assíncrona é possível verificar o log gerado neste diretório, por exemplo, quando ocorre um erro durante o envio e neste diretório que é possível verificar o que ocasionou o erro. O xmlschema é o diretório que é colocado o Schema criado no XMLSPY. O diretório xmltransf quando ocorre o envio das mensagens são gerados alguns arquivos com a extensão xls e são colocados nestes repositórios. O xmlutp é o diretório que é colocado alguns adapters auxiliares para envio e recebimento de mensagens. 4.3.4 ARQUIVOS DE CONFIGURAÇÃO Assim como para qualquer sistema, os aplicativos Datasul precisam de certos arquivos de configuração para que possam funcionar corretamente. No caso da Integração EAI, os arquivos necessários são os seguintes: InstalledApplications.xml: localizado no diretório xmlconf, este é o arquivo que gera o processo de configuração do ambiente de integração. Sua presença

23 indica que o ProPath 9 abaixo do qual ele se encontra é relativo a um produto que deve ser integrado. Sua ausência fará com que os aplicativos do produto não recebam mensagens e não possam usar os mecanismos de construção disponíveis. Na figura 13 é apresentado o XML do programa InstalledApplications com todos os seu elementos e a descrição de cada um. Figura 13 - XML Schema do arquivo InstalledApplications.xml Conforme a figura 13 o elemento raiz deste arquivo se chama InstalledApplications e tem como filhos os elementos Product (que tem como valor o nome do produto que está sendo integrado) e ListOfApplication (que pode conter várias ocorrências do elemento Application, que corresponde a um aplicativo que deve fazer parte da integração). TransactionSubscription.xml: Este arquivo apresentado na figura 14, que está localizado na pasta xmlconf, é onde são relacionadas as transações que o aplicativo deseja receber e para qual adapter cada uma delas deve ser enviada. Logo, o Control Broker usa as informações deste arquivo para fazer o roteamento das mensagens. Figura 14 - XML Schema do arquivo TransactionSubscription.xml 9 Propath é onde é informado o endereço dos programas para que seja possível a execução dos mesmos

24 Na figura 14 é apresentado a estrutura do XMLShema do transactionsubscription este arquivo que quando uma mensagem lhe é entregue, identifica a transação e monta uma lista com os aplicativos de todos os produtos que assinaram esta transação. Se não existir este arquivo, o aplicativo nunca receberá mensagens. ProcessingInfo.xml: da mesma forma como o arquivo TransactionSubscription.xml, figura 15 este arquivo está localizado no diretório específico de um aplicativo abaixo da pasta xmlconf. Neste arquivo é possível indicar a necessidade de validar as mensagens que entram e saem do aplicativo e executar programas de personalização nestas mesmas condições. Além disso, é através do arquivo ProcessingInfo.xml que é definido que as mensagens que forem geradas no aplicativo devem estar com a indicação de que são para teste e que não devem ser efetivadas nos sistemas destino. A ausência deste arquivo faz com que o sistema de integração adote a opção padrão para as características que aqui podem ser definidas. Figura 15 - XML Schema do arquivo ProcessingInfo.xml Na figura 15 é apresentado a estrutura do XMLSchema do arquivo ProcessingInfo que é responsável pelas validações da mensagens que são enviadas e recebidas nos aplicativos. MessageConstants.xml: Este arquivo figura 16, que fica localizado no diretório xmlconf, é utilizado pelos adapter da Datasul na construção das mensagens de integração. Ele tanto fornece valor para alguns elementos, como define se elementos opcionais devem ou não fazer parte das mensagens. A ausência

25 deste arquivo indica que os aplicativos do produto apenas receberão mensagens ou não utilizarão os utilitários do sistema de integração para gerá-las. Para os produtos da Datasul este arquivo é obrigatório e sua ausência provocará um erro quando um adapter de um dos seus aplicativos for construir uma mensagem. Figura 16 XML Schema do arquivo MessageConstants.xml A figura 16 apresenta a estrutura do arquivo MessageConstants e este programa é responsável pela construção das mensagens, sem este arquivo ocorrerá diversos erros durante a integração por este motivo a sua utilização é obrigatória. Config.xml: Localizado no diretório xmljserv, tem por função indicar o servidor em que se encontram os serviços de validação e transformação e as portas onde estão disponíveis. Productdir.xml: É usado exclusivamente pelo programa Java que fornece os serviços de validação e transformação. Ele deve estar presente no diretório xmljserv. É interessante notar que o serviço de validação é alimentado por XML Schemas, enquanto que o de transformação utiliza arquivos no formato XSL. ListOfProcess.xml: É usado exclusivamente pelos adapters de recebimento assíncronos, sendo que deve estar presente no diretório adapters/xml/utp. Seu objetivo é de listar os estabelecimentos que um processo especifico irá utilizar como faixa de processamento. 4.3.5 VALIDAÇÃO E TRANSFORMAÇÃO

26 Os serviços de validação e transformação são utilizados por componentes do sistema de integração. Estes serviços são fornecidos por uma aplicação Java que é disponibilizada no diretório xmljserv dos produtos Datasul. Tal aplicação precisa estar rodando apenas em uma máquina, que atuará como o servidor destes serviços para todo o ambiente. A inicialização dos serviços é feita através de um script localizado no diretório xmljserv da instalação do produto Datasul utilizado. Em ambiente Windows, deve ser aberta uma janela de comandos (Command Prompt), mudar para o diretório xmljserv na instalação do produto Datasul e digitar startjserv. Já em ambiente Unix/Linux, deve ser aberta uma nova seção, mudar para o diretório xmljserv na instalação do produto Datasul, dar permissão de execução ao arquivo startjserv e executá-lo. 4.3.6 CONFIGURAÇÃO PASSO A PASSO Durante o processo de integração, um adapter pertencente a um produto executa o Control Broker e lhe passa uma mensagem XML. O Control Broker identifica quais programas se inscreveram para receber as mensagens daquele tipo e os executa um a um. Obviamente, alguns destes programas a serem executados fazem parte de outros produtos. Portanto, é necessário configurar o atalho de execução do menu de cada produto de forma que, na sessão Progress, os bancos de dados de todos eles estejam conectados e a pasta de cada um deles faça parte do ProPath para que os programas possam ser encontrados. Além disso, para que a integração entre os produtos aconteça de maneira correta, as seguintes tarefas devem ser executadas para cada um deles: 1. Na pasta xmlconf, incluir no arquivo InstalledApplications.xml a lista de aplicativos adquiridos daquele produto. 2. Ainda na pasta xmlconf, criar o arquivo MessageConstants.xml com as informações a serem usadas nas mensagens geradas pelos aplicativos do produto. 3. Na pasta de cada um dos aplicativos do produto, localizada também em xmlconf, criar o arquivo ProcessingInfo.xml se for desejado mudar o comportamento

27 padrão do sistema de integração com relação à validação, personalização e geração de mensagens de teste. 4. No diretório xmljserv, configurar o arquivo config.xml. Este passo pode ser desnecessário se este arquivo já tiver sido configurado para executar a aplicação que disponibiliza os serviços de validação e transformação. 4.4 DESENVOLVIMENTOS DE ADAPTERS No período de estágio foram desenvolvidos alguns adapters que fazem comunicação com o sistema o GPS onde são enviados alguns dados. Os adapters desenvolvidos foram de Frota, Usuário, Viagem. O adapter de envio AXSPLD009 figura 17 apresenta um trecho do programa, este adapter tem por finalidade o envio dos dados da Frota para o GPS este adapter foi criado com a utilização do Gerador de Adapters como já foi descrito no tópico 3.4. Figura 17 Código do Adapters AXSPLD009

28 O Schema foi desenvolvido com a utilização da ferramenta XMLSPY que é um editor que auxilia na criação do Schema mencionado no tópico 3.3 e possuirá a estrutura apresentada na figura 18. Figura 18 XML Schema Frota Este adapter é executado no programa PLD0008 que é o cadastro de frotas quando for acionado o botão com globo que está destacado na figura 19 será enviado os dados da Frota do registro corrente ao GPS. Figura 19 Programa de Cadastro de Frotas

29 O adapter de envio AXSPLD008 figura 20 apresenta um trecho do fonte do programa que envia os dados do Usuário ao GPS este adapter foi criado com a utilização do Gerador de Adapters que já foi mencionada no tópico 3.4. Figura 20 Adapter AXSPLD008

30 O Schema foi desenvolvido com a utilização da ferramenta XMLSPY que é um editor que auxilia na criação do Schema descrito no tópico 3.3 e possuirá a estrutura apresentada na figura 21. Figura 21 XML Schema Usuário Este adapter é executado no programa PLD0023A Programa Relacionamento Grupos X Usuário no botão destacado figura 22, quando acionado este botão será enviado ao GPS todos os estabelecimentos que o usuário apresentado em tela tiver relacionamento. Figura 22 Programa Relacionamento Grupos X Usuário O adapter de consulta AXRPLD010 conforme figura 23 apresenta um trecho do código, foi criado com a finalidade de efetuar a consulta sobre algumas viagens do

31 CORE desta forma são enviados alguns dados a CORE e este retornando o dados solicitados para consulta. Este adapter foi criado com a utilização do Gerador de Adapters conforme descrito no tópico 3.4. Figura 23 Adapters AXRPLD010 O Schema foi desenvolvido com a utilização da ferramenta XMLSPY esta ferramenta já foi descrita no tópico 3.3. Na figura 24 é apresentada as informações que

32 são enviadas ao CORE para efetuar a consulta que são os dados como estabelecimento e uma faixa de data. Figura 24 XML Schema de Viagem dados enviados Nas figuras 25 e 26 são apresentados os dados que serão retornados pelo CORE com a utilização do adapter, este dados serão visualizado no programa PLD0032 do EMS. Figura 25 XML Schema da Viagem dos dados retornados parte I

Figura 26 - XML Schema da Viagem dos dados retornados parte II 33

34 Este adapter é executado o PLD0032G e tiver algumas viagem com o status disponível então no CORE será verificado os dados solicitados e será possível serem vistos no PLD0032. Figura 27 PLD0032G programa que executa o adapter 4.5. MANUTEÇÃO DE APLICATIVOS O processo de manutenção compreende na abertura da Ficha de Ocorrência (FO), solução, liberação para auditoria e encerramento, estas fases serão explicadas para o melhor entendimento. Durante a manutenção foi possível fazer alterações em programas para efetuar correção e melhorias de funcionalidade, está atividades estarão descritas no tópico de documentação das atividades, onde é apresentada a causa do que gerou a

35 manutenção e a alteração que foi utilizada para correção dos aplicativos, está manutenção foi feita utilizando somente a linguagem de programação Progress.. 4.5.1. SOLUÇÃO Para efetuar a correção de um programa, deve-se simular o problema procedendo conforme a FO. Esse procedimento devem ser executado para que seja possível ser efetivada correção do programa. Ao detectar o problema, o objeto que sofrerá a alteração deverá ser buscado através do RoundTable conforme descrito no tópico 3.2. Desta forma, ficará preso com o programador que está alterando o objeto, não estando disponível para outros programadores. 4.5.2. LIBERAÇÃO E ENCERRAMENTO Durante a liberação da tarefa, é feito um texto de liberação que está presente no anexo, onde que devem ser informados a causa e a solução da mesma. Neste processo é feita a liberação do objeto para backup, texto de liberação para auditoria e enviado ao Sistema Compilador. O processo de auditoria na manutenção possui dois níveis sendo a auditoria de fontes e a auditoria de negócio. Na auditoria de fonte, o auditor verifica se o código está legível, se as técnicas utilizada estão de forma correta, se não haverá nenhum problema de bloqueio de registro e se foi realmente feita a correção. Na auditoria de negócio são feitos novos testes para verificar a alteração não alterou a regra de negócio e se não casou algum impacto no sistema. Uma vez liberada, auditada e aprovada, o desenvolvedor recebe o aval para encerrar sua tarefa. Isto é feito através da opção completar task, disposta na ferramenta RoundTable. Com isso, todos os objetos que estavam reservados à tarefa são devolvidos ao uso comum, ou seja, estará disponível para que outros programadores possam novamente alterá-los.

36 5. CONSIDERAÇÕES FINAIS Durante o estágio os objetivos foram alcançados em cada uma das atividades. As atividades executadas tiveram um grande valor para o aprendizado, pois houve muita dificuldade para efetuar as alterações necessárias em alguns aplicativos por falta de um conhecimento mais aprofundado, mas que isso foi resolvido com o auxilio de algumas pessoas da equipe SHV como analistas, programadores mais experientes que me passaram as informações que faltava para realizar com sucesso a atividade de manutenção e desenvolvimento. 5.1. PRINCIPAIS DIFICULDADES A principal dificuldade encontrada para a realização do estágio foi à falta de conhecimento aprofundado na linguagem de desenvolvimento Progress e XML, para efetuar algumas das alterações solicitadas, no caso do XML tive que adquirir algumas noções sobre o EAI e também sobre a linguagem, pois não tinha nenhum noção em XML. 5.2. DISCIPLINAS QUE AUXILIARAM NA REALIZAÇÃO DO ESTÁGIO Nesse tópico, serão abordadas as principais disciplinas do Curso de Sistema de Informação na UDESC, cujos fundamentos foram essenciais para a execução das atividades realizadas durante o estágio. 5.2.1. ICC - INTRODUÇÃO A CIÊNCIA DA COMPUTAÇÃO Na programação em caracter, a maioria dos assuntos estudados em Progress tinham os mesmos fundamentos estudados na disciplina de ICC, como os conceitos de estruturas (seqüenciais, de seleção e de repetição), conceito de erros