Gilberto Holms http://gibaholms.wordpress.com/ Resumo Anotações para Certificação OCE Oracle WebLogic Portal 10g Developer Gilberto Augusto Holms @gibaholms [email protected]http://gibaholms.wordpress.com/ Portal Architecture • Portal Project Lifecycle o Architect -> Develop -> Assemble & Deploy -> Manage • Need for Enterprise Portals o Rápido desenvolvimento e deploy o Utiliza tecnologias baseadas em padrões o Gerenciamento e workflow de conteúdo integrados o Personalização e customização o Administração e segurança centralizados o High availability, performance e scalability o Flexibilidade e agilidade para futuras mudanças • WebLogic Portal Services o Portal application framework Desktops Books Pages Portlets Look and Feel o Federated Portals Consumo de portal-resources remotos via SOAP sobre HTTP ou HTTPS o Content management Conteúdo gerenciável sem retrabalho de desenvolvimento Temporização de conteúdo o Communities Foundation para gerenciar portais colaborativos É uma extensão do portal framework Compartilhamento de conteúdo Pode-se participar por registro e/ou convite o Unified user profile Define propriedades que representam características de um usuário Tais características podem ser mantidas na base do portal ou externamente em bancos ou diretórios o Personalization Capacidade da aplicação de modificar sua aparência e/ou comportamento de acordo com o usuário ou uma determinada audiência o Security & administration Usuários e perfis Visitor entitlements – diferentes permissões de acesso de acordo com perfis Delegated administration – diferentes permissões de administração de acordo com perfis Publicação e aprovação de conteúdo Portal data propagation o Enterprise search Licensa inclusa do produto Autonomy Engine e APIs de busca, gerenciamento, indexamento de conteúdo, exemplos de portlets de busca e relatório Basic WebLogic Server • WebLogic Server
Meus resumos e anotações da época que fiz a prova de certificação Oracle WebLogic Portal 10g Developer (agora substituído pelo WebCenter e ADF).
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• Need for Enterprise Portals o Rápido desenvolvimento e deploy o Utiliza tecnologias baseadas em padrões o Gerenciamento e workflow de conteúdo integrados o Personalização e customização o Administração e segurança centralizados o High availability, performance e scalability o Flexibilidade e agilidade para futuras mudanças
• WebLogic Portal Services o Portal application framework
o Federated Portals � Consumo de portal-resources remotos via SOAP sobre HTTP ou HTTPS
o Content management � Conteúdo gerenciável sem retrabalho de desenvolvimento � Temporização de conteúdo
o Communities � Foundation para gerenciar portais colaborativos � É uma extensão do portal framework � Compartilhamento de conteúdo � Pode-se participar por registro e/ou convite
o Unified user profile � Define propriedades que representam características de um usuário � Tais características podem ser mantidas na base do portal ou externamente em bancos
ou diretórios o Personalization
� Capacidade da aplicação de modificar sua aparência e/ou comportamento de acordo com o usuário ou uma determinada audiência
o Security & administration � Usuários e perfis � Visitor entitlements – diferentes permissões de acesso de acordo com perfis � Delegated administration – diferentes permissões de administração de acordo com perfis � Publicação e aprovação de conteúdo � Portal data propagation
o Enterprise search � Licensa inclusa do produto Autonomy � Engine e APIs de busca, gerenciamento, indexamento de conteúdo, exemplos de
portlets de busca e relatório Basic WebLogic Server
• WebLogic Server
Gilberto Holms http://gibaholms.wordpress.com/
o Domain � Administration Server � Configuration Repository (pasta config) � Domain Log � Cluster / Managed Servers ( + local logging )
WebLogic Workshop • WTP
o Editores HTML, CSS, XSD, etc… o Suporte a maioria dos servidores o Operações e conexões a bases de dados – Database Explorer
• JDT o Suporte aos variados módulos J2EE o Editores JSP e JSF o Servlet e EJB
• Facets o Componentes reutilizáveis em várias aplicações J2EE (WAR ou EAR) o Deployados apenas uma vez no servidor
• Merged Projects View o Mostra todas os deploys reutilizáveis – shared J2EE libraries
• Apache Beehive o NetUI Page Flow o Java Controls (FALTA PAG 106) o Web Services Metadata o Framework MVC
� View – NetUI JSP � Controller – Page Flow Controller Class (jpf) � Model – Java Control
o System Controls � Padrão do Apache Beehive
• EJB Control • JDBC Control • JMS Control
� Extensões do Workshop • Timer Control • Service Control
@ControlExtension @JdbcControl. ConnectionDataSource (jndiName = "LOCAL_ORACLE_TESTE") public interface ClienteJDBCControl extends JdbcControl { public static class Cliente { private int id ; private String nome; @Override public String toString() { return id + " | " + nome; } public int getId() { return id ; } public void setId( int id) { this. id = id; } public String getNome() { return nome; } public void setNome(String nome) { this. nome = nome; } } @JdbcControl. SQL(statement= "SELECT ID, NOME FROM CLIENTE WHERE ID = {id}" ) public Cliente buscar( int id) throws SQLException; }
• Presentation Class • Presentation ID • Presentation Style • Properties • Skeleton URI
Portlet Development • Tipos de Portlets
o JSP/HTML Portlets � Prós
• Simples para implementação, deploy, teste • Recomendado para portlets que apenas mostram dados
� Contras • Não prove arquitetura MVC • Difícil de linkar com outras JSPs • Difícil de manter e evoluir
o Java Portlet � É baseado na especificação JSR-168 � Prós
• Portabilidade entre múltiplos vendedores • Foundation para construir portlets MVC
� Contras • Não possui tooling na IDE • Desenvolvimento em baixo nível (similar a servlets) • O controlador MVC precisa ser codificado pelo desenvolvedor
o Java Page Flow Portlet � Prós
• Rápido desenvolvimento e tooling utilizando a IDE • Arquitetura MVC • Integração com Beehive Controls • Melhora o Struts, utilizando annotations
� Contras • Muitos recursos talvez sejam desnecessários para simples portlets
o Browser (URL) Portlet � Encapsula uma página da Web � Útil para integração com sistemas web legados
o Struts Portlet � Prós
• Pode-se migrar uma aplicação antiga Struts para o portal • Arquitetura MVC
� Contras • Não possui tooling na IDE • Mais complexo que NetUi (pois contém classes e XML)
o JavaServer Faces (JSF) Portlets � É baseado na especificção JSR-127 � Prós
• Componentes de tela podem ser construídos com drag-and-drop • Arquitetura MVC
� Contras • Não possui tooling na IDE • Mais complexo que NetUi
o Remote Portlet � Consumir portlets deployados em outro servidor (vide WSRP)
o Clipper Portlet � Semelhante ao browser portlet, porém ele incorpora a página dentro do próprio portal,
podendo clipar apenas um determinado conteúdo via xpath � Prós
• O resto do portal pode acessar o conteúdo e compartilhar a mesma sessão da página clipada
• Permite fazer um request via POST na página remota antes de clipar
Gilberto Holms http://gibaholms.wordpress.com/
� Contras • Não isola o conteúdo clipado, ele roda no contexto do portal • Autenticação não é criptografada • JavaScript nas páginas remotas não é garantido que funcione corretamente • Os cookies são carregados pelo portal, e não persistidos no cliente
o Se false, ele extenderá na horizontal o máximo que conseguir (width 100%). Se true, ele ocupa o mínimo espaço horizontal possível.
• Render Cacheable o Se true, o conteúdo de output sera cacheado entre requests o O cache será recusado se o usuário interagir via links ou forms o Pode-se usar o WebLogic Portal Cache Manager para controle
programático de caching • Title
� Portlet Properties • Content Presentation Class • Content Presentation Style • Offer As Remote
� Portlet Titlebar • Show Titlebar
� Presentation Properties • Presentation Class • Presentation ID • Presentation Style • Properties • Skeleton URI
• Backing Files o JspBacking � AbstractJspBacking o Sempre extender AbstractJspBacking, pois ela implementa os métodos de renderização o É criada uma instância por request o Métodos
� init(HttpServletRequest, HttpServletResponse) : void • É sempre executado, em cada request, antes do desktop ser renderizado
� handlePostbackData(HttpServletRequest, HttpServletResponse) : boolean • É executado se o recurso for visível e for “postback” (interação usuário, é
identificado pelo parametro _nfpb=true ) � preRender(HttpServletRequest, HttpServletResponse) : boolean
• É executado se o recurso for visível � dispose( ) : void
Gilberto Holms http://gibaholms.wordpress.com/
• É executado sempre, em cada request, depois de o conteudo ser renderizado � isRequestTargeted(HttpServletRequest, HttpServletResponse) : boolean
• É usado para saber se o request foi em um particular portlet o Ordem de Chamada
� Página Abriu • init
� Usuário interagiu fora de um recurso com B.F.: • init • handlePostbackData
� Usuário interagiu em um recurso com B.F.: • init • handlePostbackData • preRender • dispose
� Usuário interagiu em um recurso interno a um recurso com B.F.: • (idem ao anterior)
o Observações: � Em caso de portlet, pode ser criada em dois níveis de escopo
• netuix:portlet – atua no nível do portlet • netuix:jspContent – atua apenas na jsp do portlet (não influencia na renderização
do portlet) • Depende do recurso netuix_servlet.jar no classpath do projeto
o Portlet Preferences: � Pares de key-value para parametrização de valores � Permite que diferentes instâncias do portlet possam ter esse valor modificado em
runtime � Podem ser configuradas via Workshop (dev) ou via Console Administrativo (prod) � Recuperando os valores via API:
PortletBackingContext context = PortletBackingConte xt. getPortletBackingContext(request); PortletPreferences preferences = context.getPortlet Preferences(request); String nome = preferences.getValue( "nome" , "Giba" ); //Giba é o default caso não exista o atributo
� Recuperando os valores via TAGLIB:
Gilberto Holms http://gibaholms.wordpress.com/
• Inter-Portlet Communication o Não suportado para Asynchronous Portlets o Portlet Event Handlers (recomendado)
� Escuta eventos de um ou mais portlets, e responde com uma Event Action � Tipos de Event Handlers
• Handle Generic Event o Disparado por uma PageFlow Action de mesmo nome ou um custom
event de mesmo nome • Handle Portal Event
o Portlet states (minimize, maximize, etc) o Visibility o Portlet refresh
• Handle Custom Event o Disparado programaticamente
� Tipos de Event Actions • Change Window Mode • Change Window State • Activate Page • Fire Generic Event • Fire Custom Event • Invoke BackingFile Method • Invoke PageFlow Action • Invoke Struts Action • Invoke Faces Action
o Backing Files o Refresh Actions
� PageFlow portlets podem inscrever uma action para ser executada no refresh � É executada quando há refresh do portlet e nenhuma action foi invocada pelo usuário
o listenTo portlet property � Está deprecated
o Compartilhamento de Dados � Request Parameters
• Obter um parametro da URL do browser: HttpServletRequest outerRequest = ScopedServletUtil s.getOuterRequest( this.getRequest()); String nome = outerRequest.getParameter( "nome" );
� Request Attributes � Session Attributes
• Asynchronous Portlets o Por padrão o portal executa os portlets de forma sincrona o Todos os portlets precisam ser carregados para que o usuário possa interagir o Se o portlet for assíncrono, ele será executado em uma thread separada o Habilitando skeletons para chamada assíncrona: framework/features
� Atributo “Async Content Rendering” (a escolha é transparente ao cliente) • AJAX
o Usa o mesmo documento HTML o Suporta features como cross-portlet drag-and-drop o Não suporta XHTML o Melhor integração look-and-feel o Necessita JavaScript no browser
• IFRAME o Usa um documento HTML separado
Gilberto Holms http://gibaholms.wordpress.com/
o Suporta XHTML � Consequências do uso de portlets asíncronos
• Não suporta inter-portlet communication • Portlet Backing Files são executadas duas vezes • Comandos HTTP redirect não são suportados no portlet • Alguns commandos da PortletBackingContext API não são suportados
o Desabilitando request assíncrono em um portlet: <render:controlContext asyncContentDisabled ="true" > <netui:form action ="addToCart" > <netui:select dataSource ="actionForm.productSku" /> <netui:button value ="Submit" type ="submit" /> </ netui:form > </ render:controlContext >
o Fork Render
� É uma alternative ao portlet assíncrono � Os portlets são carregados em paralelo, o que melhora a performance geral � O cliente ainda é obrigado a esperar todos carregarem para interagir � Portlets que suportam:
o Determina como o conteúdo do portal será renderizado o É independente do conteúdo do portlet o Pode ser aplicado genericamente ou de acordo a um tipo de dispositivo (palm, etc) o Elementos do LAF:
o É um conjunto de JSPs que renderizam o conteúdo do portal em HTML o Define a estrutura do portal e aplica os elementos do Skin o Pode ser baseado em um dispositivo o Cada skeleton JSP é executada duas vezes: beginRender e endRender
• Skin o Oferece cores, imagens, fonts e estilos (CSS e JS) utilizados para renderizar o conteúdo do
portal o Skin.xml
� Indica configurações e locais para serem encontrados imagens, css e js. Indica também os commandos de link de css e include de javascript a serem renderizados no portal
o Um CSS para um determinado elemento pode ser “override” através da propriedade
Presentation Properties � Presentation Class o Podemos adicionar atributos CSS inline aos já presentes em um elemento utilizando a
propriedade Presentation Properties � Presentation Style (geralmente utilizamos para definer height – altura e overflow – rolagem)
• Chromosomes and Genes o É possível definir genes através de ${tokens} em arquivos do skin ou do skeleton (CSS, JS, JSP,
etc) e então definir seus valores através do arquivo chromosome o Por definição eles devem ser criados nas pastas “Skin” ou “Skeleton” o Denifido em arquivo.laf � Skin Chromosome Name ou Skeleton Chromosome Name
o Atenção: para utilizar chromosomes no skin, é preciso definir no skin.xml o uso de CSS e JS
inlined no html, como indicado na caixa da direita: <ns:link href ="window.css" rel ="stylesheet" type ="text/css" />
<ns:style content-uri ="window.css" type ="text/css" />
<ns:script src ="teste.js" type ="text/javascript" /> < ns:script type ="text/javascript" > alert('teste ${meuGene}'); </ ns:script >
o Observações:
Existe conceito de default.chromosome , que é onde o portal localiza os cromossomos default do skin ou skeleton. Então podemos adicionar outros arquivos .chromosome para sobrescrever parcialmente um gene particular
� Para referenciar um recurso de LAF na JSP sem ficar preso ao caminho e o laf escolhidos, utilizar o recurso de reescrita wlp_rewrite :
o Observações � Caso a tag <netuix:header/ > esteja vazia, por default serão carregados os arquivos
header.jsp e footer.jsp do skeleton � O header e o footer também podem possuir um layout atrelado � O header e o footer podem ter os mesmos contents que um portlet pode ter (vide seção
de portlets) e ainda pode incluir um portlet através da tag <netuix:portletInstance> • Layout
o Define o posicionamento dos portlets em uma página o Tipos básicos de layout:
� Flow Layout • Posicionamento lado a lado, seguindo a ordem left-to-right ou top-to-botton
� Grid Layout • São definidas linhas e colunas
� Border Layout • São definidas 5 áreas geográficas (norte, sul, leste, oeste, centro)
� Custom Layout • Arquivo .layout: define a descrição, o arquivo html de definição e os placeholders
Gilberto Holms http://gibaholms.wordpress.com/
<netuix:markupDefinition > <netuix:locale language ="en" /> <netuix:markup > <netuix:GridLayout title ="My Layout" description ="This is my custom layout" htmlLayoutUri ="/framework/markup/layout/myLayout.html.txt" markupType ="Layout" markupName="myLayout" > <netuix:placeholder title ="esquerda" description ="..." markupType ="Placeholder" markupName="myPlaceholder1" /> <netuix:placeholder title ="direita" description ="..." markupType ="Placeholder" markupName="myPlaceholder2" /> </ netuix:GridLayout > </ netuix:markup > </ netuix:markupDefinition >
• Arquivo .html.txt: define o html do layout, onde cada placeholder é identificado
pela ordem em que aparece no arquivo de layout <table class ="portalLayout" id ="thePortalLayout" width ="100%" height ="100%" > <tr > <td class ="placeholderTD" valign ="top" width ="30%" > <placeholder number ="0" /> </ td > <td class ="placeholderTD" valign ="top" width ="70%" > <placeholder number ="1" /> </ td > </ tr > </ table >
o Observações: � Ao invest de um arquivo .html.txt podemos utilizar um skeleton jsp e renderizar o layout
via código java • Theme
o É um componente “fine-grained” capaz de sobrescrever partes de um skin ou skeleton o Pode ser associado a nível de Book , Page e Portlet o Pode atuar das seguintes formas:
� Sobrescrever JSP em um skeleton � Sobrescrever imagens em um skin � Adicionar novos arquivos CSS em um skin
o Criando um Theme � Criar um arquivo de definição .theme
<netuix:markupDefinition> <netuix:locale language ="en" /> <netuix:markup > <netuix:theme name="greyout" title ="Grey Out" description ="A Theme used to de-emphasise a particular entity." markupType ="Theme" markupName="greyout" /> </ netuix:markup > </ netuix:markupDefinition >
� Criar pasta em Skin e Skeleton com o mesmo nome do theme
• Os arquivos de skeleton sobrescreverão os skeletons default � Declarar os arquivos de skin em skin.xml
• Os arquivos de skin sobrescreverão os skins default � Opcional: utilizar um arquivo structure.xml
NetUI • Struts Framework
o Open-source application framework desenvolvido para criar aplicações web baseadas na arquitetura MVC
o Componentes: � Front-Controller (ActionServlet) � Arquivo de configurações XML � Tags JSP � Classes
• Action – implementa a lógica do controller • ActionForm – encapsula dados de formulário em JavaBeans • ActionForward – implementa lógica de navegação • ActionMapping – binda actions para URIs
Gilberto Holms http://gibaholms.wordpress.com/
• NetUI (Beehive Framework) o Open-source application framework desenvolvido para criar aplicações web baseadas na
arquitetura MVC, baseado no Struts o É parte do projeto Apache Beehive o Componentes:
o É um PageFlow completo que pode ser invocado por outro PageFlow o Retorna ao PageFlow chamador via uma action de saída, que corresponde a uma action do
PageFlow chamador o Utilização:
� Modularidade � Manutenção � Reuso
• Shared PageFlows o É um PageFlow que contém uma “biblioteca” de actions e JSPs, que não é necessariamente um
fluxo completo o Seus conteúdos (actions, handlers, etc) podem ser acessados por qualquer PageFlow que o
referencie o Extende a superclasse SharedFlowController o É instanciado em qualquer PageFlow, da seguinte forma:
@Jpf.Contoller(sharedFlowsRefs = { @Jpf.SharedFlowRef(name = "sharedFlowOne" , type = example.SharedFlowClassOne. class), @Jpf.SharedFlowRef(name = "sharedFlowTwo" , type = example.SharedFlowClassTwo. class) }) public class MyController extends PageFlowController { ... }
• NetUI Tags o Wizards
� Create Form � Data Display � Data Grid � Update Form
o Tags que Disparam Actions � Anchor � Anchor Cell � Area � Button � Form � Image Anchor � Image Anchor Cell � Tree Item
o Tags Renderizadoras de Conteúdo
Gilberto Holms http://gibaholms.wordpress.com/
� Content – “texto simples” � Span – “texto dentro de uma tag <span>” � Label – “texto para input field”
o Objetos Expression Language 2.0 (EL) definidos: � requestScope / sessionScope / applicationScope / pageScope � actionForm
• Variáveis do FormBean associado à tag <netui:form> corrente (acessível apenas dentro dessa tag)
� pageFlow • Variáveis de instância do PageFlow corrente (regra nomes JavaBeans)
� Container • Objeto corrente das tags de iteração (repeater, dataGrid, cellRepeater…)
• Form Bean o Classe interna definida dentro do controller, anotada com @Jpf.FormBean :
@Jpf. FormBean public static class BeginFormBean implements java.io.Serializable {...}
o É passada para a action declarando na mesma um parâmetro do tipo do FormBean o É bindada na JSP através de uma tag netui:form e o elemento EL actionForm o Validação de FormBeans
Gilberto Holms http://gibaholms.wordpress.com/
� Feita de maneira declarativa, via Annotations � No NetUI ela é feita server-side � Regras de validação:
� Implementando Validação:
• Definindo a regra de validação (2 modos) o Na própria action (pode ser específico por action)
o Obs.: para voltar pra mesma página que submeteu o form utilizamos: @Jpf.Forward(navigateTo = Jpf.NavigateTo.currentPage )
• Exibindo a mensagem de erro na tela <netui:error key ="idade" />
� MessageBundle
• É uma alternativa às mensagens fixas • Um arquivo properties que serve de repositório de mensagens de erro • Basta declarar no controller (caminho relativo à pasta “src/ ” e sem a extensão)
o Obs.: na tag de validação, ao invés de message, definir o atributo messageKey , setando a key do properties para a mensagem
Gilberto Holms http://gibaholms.wordpress.com/
• Tratamento de Exceção o Anotação @Jpf.Catch
� Captura um certo tipo de exceção e direciona para uma action/jsp ou para um método ExceptionHandler (@Jpf.ExceptionHandler )
o Pode ser feita: � A nível de Controller
• Aplica a todas as actions do controller � A nível de Action
o Obs.: uma action pode lançar exceções declaradas (throws Exception), que também serão tratadas pelo mecanismo de tratamento de exceção
• Internacionalização o É definida através de MessageBundles o É carregado dinamicamente de acordo com o idioma do browser do cliente o Padrão de nomenclatura:
• Backing Contexts o Fornece informações sobre o estado dos elementos e permite que eles sejam modificados o Possuem a classe pai WindowBackingContext o Algumas Subclasses:
• Federated Portals o Permitem que portais compartilhem recursos (portlets) que podem ser utilizados como serviços
por outros portais o “Um Portal A está interessado em um portlet do Portal B”:
� Sem Federação: • Portal A exporta o portlet • TI migra e deploya o portlet no Portal B • Qualquer mudança no portlet precisa fazer tudo denovo
� Com federação: • Portal A publica o portlet como WebService no seu UDDI • TI do Portal B cria um “Proxy Portlet” e o configura para consumir o portlet • Qualquer mudança feita no portlet será vista automaticamente no Portal B
o Possui interoperabilidade com portais de outros vendedores e tecnologias (.NET, etc) o O que é WSRP:
� “Web Services for Remote Portlets” � É uma especificação mantida pela OASIS � Define uma interface padronizada para implementação de Federated Portals � Permite que consumidores agreguem remote markups usando SOAP � Conceitos:
• Produtor – fornece recursos via Web Services • Consumidor – consome e agrega recursos de um ou mais produtores
Gilberto Holms http://gibaholms.wordpress.com/
o Produtor WSRP � Registro de consumidor � Registro de entitlements � Federated portlets / books / pages � WS-Security / SAML � Integração com Service Registry
o Consumidor WSRP � Proxy portlets / books / pages � Visitor Entitlements � User Identity Propagation (SAML) � User Profile Propagation
• Implementando um Produtor WSRP o Adicionar facet “WSRP Producer” o Extender o domínio adicionando o template wsrp-simple-producer.jar o Nos arquivos que deseja oferecer (.portlet / .book / .page), setar propriedade:
Portlet Properties � Offer As Remote o O Producer WSDL se tornará disponível em: http://<host>:<port>/<webapp>/producer?wsdl o Configuração do Producer
o O Visitor Entitlement é realizado através de “WSRP Properties” setadas no consumidor, que são enviadas para o produtor no momento do registro:
� Criar um “Property Set” no DataSync Project � Adicionar properties no Property Set � Registra o Property Set no arquivo wsrp-producer-config.xml � Entitlement: no Console Administrativo, criar o entitlement utilizando “Role Expression”
associado ao Property Set criado, definindo uma regra com o valor de uma propriedade • Implementando um Consumidor WSRP
o Configuração do Consumer
o Criar um portlet do tipo “Remote Portlet” o Digitar a url do Producer WSDL e clicar em “Register” o Serão exibidos todos os portlets remotos que o produtor oferece para que seja escolhido um o Serão exibidas todas as propriedades que o Producer declara no seu Property Set, para que elas
sejam preenchidas pelo consumidor
Gilberto Holms http://gibaholms.wordpress.com/
o Atenção: books e pages remotos podem ser adicionados apenas em portais em produção, através do Console Administrativo (e não no workshop)
• Inter-Protlet Communication o É feita da mesma forma, criando Event Handlers no portlet proxy e Actions no portlet local
• User Profile o O consumidor informa as User Profile Properties que o produtor declarar como necessárias, na
hora do registro • Transferencia de Dados
o Um protlet local pode trocar dados (objeto Serializable) com um portlet remoto, da seguinte forma:
• Interceptors
o É possível que um consumidor declare interceptors nas chamadas do portlet remoto, para uma lógica qualquer:
� Error handling / validation � Implementação de cache � Mudança de markup � Mudança de HTTP Headers
Content Management • Motivações:
o O conteúdo de um site é modificado muito frequentemente o O site precisa ser ágil, sem a necessidade de um desenvolvedor o Gerenciamento de mudança do conteúdo
• Um Content Management System (CMS) deve prover: o Ferramentas para administração e desenvolvimento o Ferramentas para criação / publicação de conteúdo o Um repositório (storage) estruturado para armazenamento do conteúdo o Sistema de busca Property-based
• Virtual Content Repository o É o repositório lógico para acesso e organização de conteúdos no console administrativo o Pode agrupar vários repositórios físicos logicamente
• Content Repository o É o repositório físico, onde realmente fica guardado o conteúdo o Opções de Content Repository
� BEA Repository • Database (default) • File System
o Mais performático o Se utilizado com versionamento, o conteúdo antigo é guardado na base
de dados o Porém, não é transacional
� Third-Party Repository • Repositórios de outros fabricantes (ex. Documentum)
o Por padrão, o versionamento de conteúdo (“Library Services ”) vem desabilitado o Podemos utilizar Content Workflow somente em repositórios versionados
• Content Types o É o template, a definição de um determinado tipo de conteúdo
Gilberto Holms http://gibaholms.wordpress.com/
o Suas características são definidas a partir de “Properties ”, que podem ser: � Boolean � Long Integer � Number Decimal � String � Date/Time � Binary – um arquivo qualquer � Nested Content Type – um sub-elemento complexo (outro Content Type) � Link – algum outro conteúdo já implantado
o Opções gerais para as Properties: � Required � Read Only � Primary Property
• Uma por content-type, podendo ser utilizada para otimizar a busca de conteúdos � Searchable
• Pode ser incluída na busca de conteúdo � Is Explicit
• Mapeia o valor para uma coluna específica na tabela do CMS � Allow Multiple Values
• Uma lista de valores � Restrict Values
• Cria um domínio de valores permitidos o Hierarquia de Content Types
� Abstract Content Types • Não podem virar conteúdo, serve apenas para ser “herdado ” (é um) ou
“agregado ” (tem um) por outros Content Types o Adicionando conteúdo:
� Console Administrativo do Portal � Através do Windows Explorer, se o WebDAV estiver configurado � Programaticamente, utilizando CMS Controls e Content API � Usando Propagation Tools
o Content Folders � Pastas utilizadas para agrupar lógicamente conteúdos � Importante pois permite setar Visitor Entitlements e Workflow em folder-lever
• WebDAV o Web-based Distributed Authoring and Versioning o É uma extensão do protocolo HTTP o Permite que administradores publiquem conteúdo através do Windows Explorer o Pode ser utilizada em um repositório por vez o O WebDAV determina o Content Type associado ao conteúdo de duas formas:
� Utiliza o Content Type default associado ao repositório � Utiliza o Content Type default associado à pasta atual
o Para isso, configurar as seguintes propriedades no repositório: � WEBDAV_ENABLED e WEBDAV_TYPE
o Pode ser ativado apenas em repositórios do tipo “BEA Repository” o Content Workspace
� Uma user-view do conteúdo atual � Gerencia check-in / check-out de conteúdo e os Assigned Itens para sua role no caso do
uso de workflow o Content Workflow
� Workflow default:
Gilberto Holms http://gibaholms.wordpress.com/
� Criando workflows customizados • Através de arquivo de configurações XML • Cada estado do workflow é definido atrave´s de classes de estado default do
produto, chamadas de Workflow Action Class • Exemplo de uma declaração de transição do status 2 para o status 6:
o O Portal fornece aos desenvolvedores alguns recursos para publicação de conteúdo gerenciável: � Content Selectors � Content Placeholders � Campaigns � JSP Tag Libraries � Java API e Controls
o Content Placeholders � A cada request no portal, faz uma busca de conteúdo através de property values
(através de uma query) e randomiza, escolhendo um conteúdo para exibir � Comportamento de um banner � Suporta prioridades e balanceamento de peso � Suporta personalização utilizando properties e campaigns � É criado no projeto DataSync � Exemplo de query
source = ’edudev ’ && !(title like ’Jav a*’) keywords contains ’bea’ || title = ’bea’ expireDate > now
� Existem propriedades pré-definidas pelo portal, que podem ser utilizadas na query:
� Exemplo de content query via TagLib: <cm:search id ="nodes" query ="title like ’Java*’ && cm_objectClass = ’books’" />
� Exibindo o placeholder na página JSP:
<ph:placeholder name="/placeholders/myPlaceholder.pla" height ="100" width ="150" /> � Propriedades que podemos utilizar na tag ph:placeholder:
Gilberto Holms http://gibaholms.wordpress.com/
o Content Selectors � A cada request no portal, faz uma busca de conteúdo através de property values
(através de uma query) e retorna todos os content nodes localizados � Suporta personalização utilizando properties e segments � Exibindo o selector na página JSP:
• A Tag pz:contentSelector retorna o array de nodes encontrados, e então utilizamos uma tag netui-data:repeater para iterar sobre os nodes e exibí-los como necessário:
� Obs.: os entitlements necessários para acessar o content são determinados a partir da identidade do usuário obtida do request: new ContentContext( this.getRequest())
Gilberto Holms http://gibaholms.wordpress.com/
o API Overview
o Content Management Controls � O portal oferece Beehive Content Controls para acessar a CMS API de forma
simplificada � Principais CMS Controls:
• Content Node Control o Substitui o INodeManager o Permite:
� Adicionar novos Nodes � Gerencias Nodes � Obter Property e ID dos Nodes � Obter Nodes filhos
• Content Search Control o Substitui o ISearchManager o Permite:
� Buscar conteúdos através de uma content query � Retorna uma SortableFilterablePagedResult , que é uma lista
que pode ser ordenada, filtrada e paginada o Content Management JSP Tags
� Estas funcionalidades também são fornecidas através de tags: • <cm:search> • <cm:getNode> • <cm:getProperty>
� Os conteúdos retornados em forma de lista podem ser iterados por qualquer tag iterativa ou scriptlet
� Para mostrar propriedades binárias (ex.: imagens), é preciso utilizar o ShowBinary servlet
� Exemplos: <cm:getNode path ="/BEA Repository/news" id ="node" /> <% String nodeName = node.getName(); %> <cm:getNode path ="/BEA Repository/news/news1" id ="node" /> <cm:getProperty id ="node" name="title" /> <cm:search id ="nodes" query ="source ='edudev'" /> <% for( int i = 0;i < nodes.length; i++) { ... } %> <cm:getNode path ="/BEA Repository/MyImageContent" id ="imageNode" /> <img src =" <%=request.getContextPath() %>/ShowBinary?nodePath= ${imageNode.path} /MyBinaryProperty " />
• Content Management Administration API
o É uma API parecida com a CMS API, porém permite a administração do sistema de Content Management do portal:
Gilberto Holms http://gibaholms.wordpress.com/
� Criar Repository � Criar novo Folder ou Node � Criar novo Content Type � Adicionar um novo Workflow � Check-in e Check-out de conteúdos
o Usuários precisam estar autenticados e possuir permissão para as operações o Pacote com.bea.federated
o Content Administration Controls � Também são fornecidos Beehive Content Administration Controls para simplificar o uso
da API � Principais CMS Administration Controls:
o Content Node Control o Content Repository Control o Content Type Control o Content Workflow Control
• Third-Party CMS Systems Integration o Arquitetura geral do sistema de CMS da BEA:
o É criado como um Repository, que é associado a um Virtual Content Repository o Técnicas de integração que podem ser utilizadas:
� Implementação do BEA Content Repository Service Provider Interface (SPI) � Implementação da JSR-170 Service Provider Interface (SPI) – “Content Repository for
Java API” � Propagação de conteúdo diretamente para as tabelas da BEA � Portlets de conteúdo customizados
o Se o fabricante optar pela JSR-170, é necessário implantar uma Bridge . O portal fornece esta bridge
Gilberto Holms http://gibaholms.wordpress.com/
o Fabricantes que já se integram com o BEA Portal � Documentum � Interwoven � FatWire � Stellent
Portal Administration • Atividades possíveis de administração:
o Usuários e profiles o Modificações finais em desktops e seus componentes o Setar permissão para componentes do portal de acordo com roles o Delegar capacidades administrativas para outros administradores o Publicar e aprovar conteúdo o Application deployment o Portal data propagation
• Um portal tem dois ciclos bem definidos: Development e Administration o Development
� Criação do arquivo .portal , que é apenas o template de um portal o Administration
� Assemblar templates para criar um portal customizado, focado em um tipo de usuário � Aplicar segurança nos recursos do portal � Outras atividades post-development
• Portal Template vs. Portal Desktop Instance o O arquivo .portal é apenas um template (filesystem portal ) o A partir dele são criadas instâncias reais de portal (database portal ) o Na instância real podemos modificar books, pages, portlets e look-and-feel, sem que o template
.portal original seja alterado o A instância real (Desktop) é uma “view” do portal direcionada a um determinado publico
• Portal Propagation Tool o Permite que mudanças de LDAP e base de dados sejam propagadas de um ambiente para outro o Desta forma, podemos por exemplo replicar no ambiente de produção todas as configurações
realizadas no ambiente de homologação o Realizado através do Workshop ou script Ant o Podemos propagar:
• Portal XIP Tool
o Administradores podem fazer mudanças drásticas em um template de portal para criar sua instância em produção
o O XIP Tool permite recriar template files (.portal, .book, .page) a partir dos últimos desktops usados em produção, para que as alterações feitas via console administrativo possam ser replicadas posteriormente
• Portal Library Resources o São mostrados todos os recursos disponíveis para o portal deployado (books, pages, portlets,
lafs, etc…) o Recursos que são sincronizados automaticamente durante o desenvolvimento:
� .portlet � .shell � .laf � .layout � .theme
Gilberto Holms http://gibaholms.wordpress.com/
o Recursos que precisam ser recarregados explicitamente: � .portal � Books � Pages
• Instância real – Production Desktop o URLs do production desktop:
o Formas de criar um Production Desktop: � Utilizar um template em uma lista � Assemblar manualmente com os recursos da library � Utilizar um arquivo .portal
o No production desktop podemos setar/modificar: � Details – resumo dos atributos � Contents – gerenciar child resources (boos/pages) � Preferences – gerenciar Portlet Preferences � Visitor Entitlements � Delegated Admin
Portal Security • WebLogic Security Realm:
• Users and Groups o Entidades do WebLogic Server Realm o Podem ser gerenciados pelo console do WebLogic Server ou pelo console administrativo do
Portal • User Profiles
o Dados adicionais sobre a entidade (ex.: endereço, telefone, emal, etc…) o São gerenciados pelo console administrativo do Portal o São agrupados em Property Sets
• Roles o São classificações (perfis/papéis) para usuários o Podem ser atribuídos/classificados usuários das seguintes formas:
� Grupos � Users � Regras com atributos de User Profile � Regras com atributos gravados na sessão (HttpSession ) � Tempo / hora
Gilberto Holms http://gibaholms.wordpress.com/
• Visitor Entitlements o É um mecanismo para determinar “quem” pode acessar qual recurso e “o quê” ele pode fazer o É a permissão é concedida a nível de “Role ”
o Podem ser aplicados a nível de � Desktops � Book � Page � Portlet � Conteúdo
o Podem ser concedidas permissões de: � View � Minimize � Maximize � Edit � Remove
o Já possui automaticamente dois Entitlements padrão: � Authenticated Visitor – todos que estão autenticados (independente da role) � AnonymousVisitor – todos que não estão autenticados
• Visitor Tools o Permite que um Desktop seja customizado por cada usuário, para si próprio o A customização é persistida e permanece ativa para os próximos acessos do usuário o O usuário pode customizar:
� Adicionar/remover Books e Pages � Posição dos Books e Pages � Adicionar/remover Portlets � Posição dos Portlets � Trocar Look-and-Feel
o Pode ser aplicado apenas a um Production Desktop (não a nível de arquivo .portal) o É preciso adicionar a “facet” chamada Portal Visitor Tools o É criada uma pasta “/visitorTools” com os componentes necessários e o Visitor Tools Portlet o Visitor Tools Portlet
� É o portlet que permite que o usuário gerencie sua view do desktop � Geralmente é incluído no Header (arquivo .shell) � Requer que o usuário esteja autenticado � Fica em “/visitorTools/visitorMenu.portlet”
o Através do Console Administrativo do Portal, o administrador pode dar LOCK em placeholders, o que disabilitará a customização daquele placeholder específico
o O Entitlement para definir quem pode customizar qual recurso deve ser atribuído através da Library , e não da instância do desktop
GroupSpace • Conceitos de Portais Colaborativos
o Portais que permitem o compartilhamento de conteúdo entre usuários, como discussões, notificações, anúncios, email, etc.
o Principais requisitos para colaboração: � Interface unificada � Member invitation e gerenciamento automático � Controle de acesso à informação � Ser extensível, para contemplar futuros requisitos
• Weblogic Portal Communities o Weblogic Portal Community Framework
� Base para criar e manter Portais Colaborativos
Gilberto Holms http://gibaholms.wordpress.com/
� Extende o core do Weblogic Portal � Community
• É uma coleção de recursos de portal que fornecem implementação dos requisitos de colaboração
• Suporta compartilhamento de conteúdo • Suporta member registration / invitation
� Uma Community é uma forma especializada de um Portal Desktop � Componentes de uma Community:
• Componentes comuns de portal (como Books, Pages e Portlets) • Assemblado através do Console Administrativo do Portal • Pode ser iniciado através de um template criado no Workshop • Pode ser customizável através de Visitor Tools
� Community Templates • Da mesma forma que portais normais são criados através de templates .portal,
as Communities são criadas por templates .community e .ctmeta o Gerenciamento de Usuários nas Communities
� Os usuários podem se tornar membros de uma community das seguintes formas: • Respondendo a um link de convite na página do portal • Respondendo a um email de convite • Registrando-se sem um convite (communities públicas)
� Papéis (roles) das Communities • Creator
o Cria e gerencia comunidades, todas configurações de portlets, automaticamente é convidado para fazer parte da community
• Owner o Apenas gerencia comunidades, todas configurações de portlets,
automaticamente é convidado para fazer parte da community • Contributor
o Utiliza todas as features dos portlets, exceto deletar conteúdo • Viewer
o Utiliza apenas features read-only dos portlets • GroupSpace Community
o É uma aplicação completa pré-definida criada sobre o Community Framework, com vários recursos prontos para serem customizados e reutilizados
o Os usuários podem definir a visibilidade do conteúdo que postam nos GroupSpace Portlets: � Community
• Todos os membros da community � Private
Gilberto Holms http://gibaholms.wordpress.com/
• Apenas o usuário que postou � Personal
• Apenas o usuário que postou, e o conteúdo é visível em todas comunidades que o usuário é membro
o Todo o conteúdo das GroupSpace Communities são modelados através de Content Types, que são criados automaticamente pelo aplicativo
o Os GroupSpace portlets suportam diversos tipos de customização via código
Content Management – Principais Conceitos 1 – Virtual Content Repository É o repositório lógico para acesso aos conteúdos pelo console de administração. Independe do tipo de repositório físico e pode agrupar vários repositórios físicos logicamente. 2 – Repository É o repositório físico, onde realmente fica guardado o conteúdo. Pode ser dos seguintes tipos:
• BEA Repository o Tipo Database (é o default)
Já vem pré-configurado, utiliza base de dados tanto para guardar os metadados quanto o conteúdo.
o Tipo Filesystem Utiliza base de dados para guardar os metadados e o disco rígido para guardar o conteúdo binário (tem melhor performance). Se utilizado com versionamento, o conteúdo antigo é guardado na database, assim se assegurando que se houver problemas no filesystem, os arquivos anteriores possam ser recuperados. Contra: não é transacional, se a rede cair durante uma alteração, ela será perdida.
• Third-Party Repository Integração com repositórios de outros fabricantes.
O versionamento (Library Services) por padrão vem desabilitado. Para habilitar: Aba “Repositories” > Selecione o repositório > Library Services Só podemos utilizar workflow em repositórios versionados. 3 – Content Types É uma definição de um “Tipo de Conteúdo”, que pode ter propriedades de vários tipos “primitivos” (string, data, binário...) ou ainda um sub-elemento de outro “Content Type” complexo. Será o template para que a pessoa responsável por publicar conteúdo utilize, portanto deve ser bem descrito. 4 – Content Folders São pastas criadas dentro da aba “Content” para organizar o conteúdo. Servem para organizar logicamente o conteúdo, mas são importantes porque também permitem setar workflow e autorização separados por pasta (aliás, permite tanto configurações folder-level quanto file-level). 5 – Content Workflow Permite um fluxo de aprovação para o conteúdo. Lembrete: precisa habilitar o versionamento (Library Services) do repositório. O portal fornece um workflow default, mas podemos criar um personalizado: - Criar um XML de definição de workflow - Adicionar ele no repositório - Setar as configurações de autorização dos steps do workflow - O workflow fica disponível para ser associado a qualquer recurso Podem ser associados a Content Folders, Content Types e Contents. 6 – Content É um conteúdo criado (a implementação de um Content Type), pronto para ser carregado e exibido no portal.
Gilberto Holms http://gibaholms.wordpress.com/
7 – Detalhamento: Content Type
• Property definitions: todo o metadado que possa ser útil obter no portal (como largura da imagem ou tamanho), ou para utilizar “Interaction Management”.
o Boolean o Long Integer o Number Decimal o String o Date/Time o Binary – um arquivo qualquer (como por exemplo uma imagem) o Nested Content Type – um sub-elemento complexo (outro content type) o Link – algum outro conteúdo implementado
• Property options: opções gerais da propriedade: o Required – é obrigatória ao criar o conteúdo o Read Only – valor não pode ser alterado o Primary Property – apenas uma por content type, com isso podemos criar uma busca de
conteúdo apenas por esse campo para otimizar a consulta o Searchable – pode ser incluída na busca de conteúdo o Is Explicit – mapeia o valor para uma coluna específica da tabela do CMS o Allow Multiple Values – permite mais de um valor para a propriedade (array) o Restrict values – cria um choice (domínio) de valores permitidos
• Abstract Content Types: tipos que não podem virar conteúdo diretamente, são apenas pedaços de um content type maior, ou seja, não têm significado sozinhos.
• Content type inhiterance: é quando você deseja que content types herdem propriedades de um outro content type
• Content workflow: associa o tipo a um workflow, ou seja, todo o conteúdo criado a partir desse tipo possuirá este workflow associado.