Modelos Dinâmicos e Estáticos: Criando Novas Entidades e Propriedades em Tempo de Execução

O gerenciador de membro virtual é configurado para usar o modelo dinâmico ou o modelo estático. É possível criar em tempo de execução novos tipos de entidade, novos tipos de propriedade, e incluir nos novos tipos de entidade tipos de propriedade existentes ou novos.

Sobre Esta Tarefa

É necessário chamar a API createSchema do gerenciador de membro virtual para criar novos tipos de entidade, novos tipos de propriedade e incluir tipos de propriedade novos ou existentes nos novos tipos de entidade em tempo de execução, sem reiniciar o gerenciador de membro virtual. O Adaptador LDAP e o Adaptador de BD prontos para uso suportam esse tipo de procedimento. Neste exemplo, você deseja criar um novo tipo de entidade chamado ContactPerson, que é estendido a partir do tipo de entidade integrado do gerenciador de membro virtual, PersonAccount. Você também deseja criar um novo tipo de propriedade chamado cellPhone e incluir esse tipo de propriedade nesse tipo de entidade. Esse exemplo usa o Adaptador LDAP.

Execute o seguinte:

Procedimento

  1. Se os adaptadores subjacentes incluírem o Adaptador LDAP, assegure-se de que o esquema de atributo LDAP correspondente do novo tipo de propriedade seja definido no servidor LDAP e contido pelas classes de objeto LDAP do tipo de entidade. O gerenciador de membro virtual não fornece função para criar e atualizar o esquema LDAP no servidor LDAP. Neste exemplo, a classe de objeto eContactPerson e o atributo cellularTelephoneNumber precisarão ser criados, se não estiverem predefinidos.

    Se os adaptadores subjacentes incluírem o Adaptador de BD, nenhuma preparação adicional será necessária.

  2. No lado do cliente, construa um gráfico de dados para criar o novo tipo de propriedade.

    O objeto de dados EntitySchema é usado para criar o novo tipo de entidade e o objeto de dados PropertySchema é usado para criar o novo tipo de propriedade. Ambos os objetos de dados precisam especificar o URI do namespace sob o qual o novo tipo de entidade e propriedade é criado. O novo tipo de entidade precisa especificar o tipo de entidade pai a partir do qual ele se estende.

    Além das informações de esquema, ambos os objetos de dados especificam as informações de configuração necessárias para o gerenciador de membro virtual e o adaptador subjacente (Adaptador LDAP) para suportar os novos tipos de entidade e propriedade. Por exemplo, o pai padrão e a propriedade RDN são necessários para incluir essa nova entidade no arquivo XML de configuração do gerenciador de membro virtual (wimconfig.xml). O pai padrão definido na região é criado através do Gerenciador de Configuração. Os atributos objectClasses e objectClassForCreate são necessários ao Adaptador LDAP para mapear a nova entidade para as classes de objeto LDAP correspondentes. Para uma nova propriedade, o Adaptador LDAP precisa do nome do atributo LDAP correspondente, que pode não ser igual ao nome da propriedade. Se não forem iguais, você deverá incluir uma configuração de atributo LDAP e especificar o nome da propriedade do gerenciador de membro virtual correspondente. Para obter informações sobre essa configuração usando a interface da linha de comandos, leia sobre o comando addIdMgrLDAPAttr em Grupo de comandos IdMgrRepositoryConfig para o objeto AdminTask no centro de informações do WebSphere Application Server.

    A seguir, o gráfico de dados de amostra. O elemento entitySchema é usado para definir o esquema para a entidade ContactPerson. O elemento entityConfig contém as informações de configuração para o tipo de entidade. Por exemplo, o elemento actionNotAllow é usado para especificar que esse tipo de entidade não pode ser excluído. O elemento propertySchema é usado para definir o esquema para a propriedade cellPhone.
    <?xml version="1.0" encoding="UTF-8"?>
    <sdo:datagraph xmlns:sdo="commonj.sdo"
        xmlns:wim="http://www.ibm.com/websphere/wim">
      <wim:Root>
        <wim:schema>
          <wim:entitySchema entityName="ContactPerson" 
                            nsPrefix="yourext" 
                            nsURI="http://www.yourco.com/wim/yourext"
              parentEntityName="PersonAccount">
            <wim:entityConfiguration defaultParent="cn=users,dc=yourco,dc=com" 
                                     rdnProperty="uid">
              <wim:actionNotAllow actionName="delete"/>
              <wim:metaData name="objectClasses">
                <wim:values>eContactPerson</wim:values>
              </wim:metaData>
              <wim:metaData name="objectClassesForCreate">
                <wim:values>eContactPerson</wim:values>
                <wim:values>inetOrgPerson</wim:values>
              </wim:metaData>
              <wim:metaData name="rdnProperties">
                <wim:values>uid</wim:values>
              </wim:metaData>
            </wim:entityConfiguration>
          </wim:entitySchema>
          <wim:propertySchema nsURI="http://www.yourco.com/wim/yourext"
                              dataType="STRING" 
                              multiValued="true" 
                              propertyName="cellPhone">
            <wim:applicableEntityTypeNames>yourext:ContactPerson</wim:applicableEntityTypeNames>
          </wim:propertySchema>
        </wim:schema>
      </wim:Root>
    </sdo:datagraph>
    Nota: Para obter mais informações sobre o uso dos objetos de dados propertySchema e extensionPropertySchema, consulte a seção Estendendo o Esquema de Propriedade no tópico Pré-requisitos de Programação. Além disso, leia sobre Configurando um repositório de extensão de propriedade em uma configuração de repositório federado no centro de informações doWebSphere Application Server.

Resultados

No lado do cliente, o aplicativo de exploração do gerenciador de membro virtual chama a API createSchema do gerenciador de membro virtual através do Provedor de Serviços Local. O Provedor de Serviços Local detecta que essa chamada altera o esquema e atualiza o esquema local (ECore) após a finalização da chamada da API createSchema.

No lado do servidor, o Schema Manager recebe a chamada da API do cliente. O Schema Manager primeiro verifica se os novos tipos de entidade e propriedade já existem e lança uma exceção caso existam. Em seguida, o Schema Manager cria um novo modelo ECore (EPackage) com o URI do namespace (http://www.yourco.com/wim/yourext), se ele não existir ainda. Em seguida, ele incluirá o esquema dos novos tipos de entidade e propriedade no modelo ECore na memória.

O Schema Manager inclui o esquema do novo tipo de entidade e propriedade no arquivo wimxmlextension.xml. Se esse arquivo não existir, um novo arquivo será criado. A seguir, o conteúdo de amostra do arquivo wimxmlextension.xml após essa operação ser concluída.
Nota: As informações de configuração não são gravadas nesse arquivo XML.
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo"
    xmlns:wim="http://www.ibm.com/websphere/wim">
  <wim:schema>
    <wim:entitySchema nsPrefix="yourext" 
                      nsURI="http://www.yourco.com/wim/yourext"
                      entityName="ContactPerson" 
                      parentEntityName="PersonAccount"/>
    <wim:propertySchema nsURI="http://www.yourco.com/yourext" 
                        dataType="STRING" 
                        multiValued="true"
                        propertyName="cellPhone">
      <wim:applicableEntityTypeNames>ContactPerson</wim:applicableEntityTypeNames>
    </wim:propertySchema>
  </wim:schema>
</sdo:datagraph>
O Schema Manager então chama o Gerenciador de Configuração.
O Gerenciador de Configuração inclui as informações de configuração dos novos tipos no arquivo XML de configuração do gerenciador de membro virtual (wimconfig.xml). A seguir, as seções incluídas para esse novo tipo de entidade ContactPerson em wimconfig.xml depois que essa operação é concluída.
<config:supportedEntityTypes defaultParent="cn=users,dc=yourco,dc=com" 
                             name="yourext:ContactPerson">

      <config:rdnProperties>uid</config:rdnProperties>
    </config:supportedEntityTypes>

<config:repositories xsi:type="config:LdapRepositoryType" ...>

      <config:EntityTypesNotAllowDelete>yourext:ContactPerson</config:EntityTypesNotAllowDelete>

      <config:ldapEntityTypes name="yourext:ContactPerson">
        <config:rdnAttributes name="uid"/>
        <config:objectClasses>eContactPerson</config:objectClasses>
        <config:objectClassesForCreate>eContactPerson</config:objectClassesForCreate>
        <config:objectClassesForCreate>inetOrgPerson</config:objectClassesForCreate>
      </config:ldapEntityTypes>
    </config:repositories>
O Schema Manager então chama o Gerenciador de Repositório.
O Gerenciador de Repositório chama o método SPI createSchema de todos os adaptadores. Os adaptadores que suportam a criação do esquema então executam as operações necessárias para suportar o novo esquema. Como exemplos, o Adaptador LDAP atualiza o cache para refletir as mudanças no esquema e na configuração. O Adaptador de BD cria o esquema da nova entidade e propriedade no banco de dados e atualiza os caches.
Nota: Os adaptadores que não suportam a criação de esquema, por exemplo, o Adaptador de Arquivo que não suporta a criação de novos tipos em tempo de execução, emitem uma OperationNotSupportedException.

Se pelo menos um adaptador de repositório suportar a criação de novas entidades e não emitir a OperationNotSupportedException, o gerenciador de membro virtual retornará os IDs desses repositórios no gráfico de dados de saída.

No lado do cliente, depois que a chamada da API createSchema é retornada, o Provedor de Serviços Local chama a API getEPackages para recuperar os últimos esquemas. O Provedor de Serviços Local registra novamente os esquemas na JVM cliente. Os aplicativos de exploração podem chamar a API create do gerenciador de membro virtual para criar uma nova entidade do tipo ContactPerson com a propriedade cellPhone. O gerenciador de membro virtual não precisa ser reiniciado para que a mudança no esquema se torne ativa.



Termos de uso | Feedback