Fast Check-in com UCM 11g

Recentemente estive em um cliente (bah, guri!) que precisava de um recurso para carregar centenas ou milhares de documentos metadata-only no UCM. E o checkin normal estava gerando uma fila de indexação muito grande, sendo que a indexação era desnecessária neste caso.

Felizmente, na versão 11g do UCM o recurso de Fast Check-In faz parte do core do produto, e pode ser usado de forma muito simples, com o uso de um parâmetro adicional.

Neste post vamos ver como trabalhar com o Fast Check-in. O ambiente é um UCM 11.1.1.6, rodando em Windows. Para fazer os checkins, eu criei uma aplicação Java simples, que usa a API RIDC para fazer os check-ins. Para fins de teste, criei 2 campos, PersonName e PersonNumber:

image

Nesta aplicação, o usuário diz quantos conteúdos ele quer criar, define o nome e número da pessoa, e diz se quer usar o parâmetro de Fast Check-In. O código fica desta forma:

// create the manager and context
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.createClient(“idc://localhost:4444”);
IdcContext userContext = new IdcContext (“weblogic”);

//get the binder and set checkin metadata
DataBinder binder = idcClient.createBinder ();
binder.putLocal (“IdcService”, “CHECKIN_NEW”);
binder.putLocal (“dID”, “”);
binder.putLocal (“dDocName”, “”);
binder.putLocal (“dDocAuthor”, “weblogic”);
binder.putLocal (“dDocAccount”, “”);
binder.putLocal (“dDocType”, “Document”);
binder.putLocal (“dSecurityGroup”, “Public”);
binder.putLocal (“dRevLabel”, “1”);
binder.putLocal (“createPrimaryMetaFile”, “true”);
binder.putLocal (“dDocTitle”, “Document for Person “+personName+ ” 000″ + i );
binder.putLocal (“xpersonName”, personName + ” 000″ + i );
binder.putLocal (“xpersonNumber”, “000” + i + personNumber );
binder.putLocal (“primaryFile”, “” );
//verify checkbox to set Fast Checkin parameter
if (FCCheck.isSelected()){
binder.putLocal (“DirectReleaseNewCheckinDoc”, “1” );
}
//execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);
//get the binder
DataBinder serverBinder = response.getResponseAsBinder ();

Ou seja, o documento vai ser do tipo Document, com grupo de segurança Public. O título vai ser ‘Document for Person’ + o nome da pessoa. Também existe uma checagem para ver se o checkin tem que ser feito com o parâmetro do Fast Check-In. O parâmetro neste caso é o DirectReleaseNewCheckinDoc=1.

Para o primeiro teste, não iremos usar o Fast Check-In. Após feito os checkins, os documentos já aparecem na tela de busca:

image

Lembrando que estes documentos passaram pelo processo normal de indexação full-text (o UCM está configurado para OracleTextSearch).

Agora iremos criar outros 5 conteúdos, mas desta vez usando o Fast Check-In:

image

Os documentos foram publicados com o recurso de Fast Check-In, o que fez com que eles não seguissem pelo processo de conversão-indexação-workflow. Mas isso permite que eles estejam disponíveis (Released) praticamente imediatamente, o que é um requisito para este caso específico.

Mas agora uma surpresa: quando vamos na tela de busca, não conseguimos visualizar os documentos que criamos:

image

Mas por quê eles não aparecem? O motivo está na documentação:

DirectReleaseNewCheckinDoc: Directs content items being checked in to bypass Inbound Refinery, workflow, and indexing. The default is 0. To enable, set DirectReleaseNewCheckinDoc=1.

Before you enable this setting, take into account the following important considerations.

  • A content item checked in this way can only be found by searching with DATABASE.METADATA. However, other content items can still go through regular checkin and be FULLTEXT indexed.

Ou seja, quando formos buscar este conteúdo, devemos usar um parâmetro de busca para dizer que queremos fazer a busca por metadados. Segundo a documentação, o parâmetro de busca que deve ser usado é o SearchEngineName, que neste caso deve ter o valor ‘database’.

Para fazer este teste, montei um código IDOC muito simples, que executa duas buscas, uma usando o default e outra usando este parâmetro. O código ficou desta forma:

<h3> Regular Search for Type Document </h3>

 <$QueryText=dDocType <matches> `Document`“$>
<$ResultCount=100$>
<$executeService(“
GET_SEARCH_RESULTS“)$>
 <$if SearchResults$>
    <b> Found <$TotalRows$> Results </b> <br>
  <table border=”1″ width=”80%” align=”center”>
  <tr bgcolor=”#CCCCCC”>
     <td align=”center”> <b> Doc ID </b> </td>
     <td align=”center”> <b> Doc Title </b> </td>
     <td align=”center”> <b> Person Name </b> </td>
<td align=”center”> <b> Person Number </b> </td>
</tr>
  <$loop SearchResults$>
  <tr>
<td
align=”center”>
         <a href=”<$HttpCgiPath$>?IdcService=DOC_INFO_BY_NAME&dDocName=<$dDocName$>” target=”new”>
          <$dDocName$></a>
</td>
<td>
<$dDocTitle$></td>
<td>
<$xpersonName$></td>
<td>
<$xpersonNumber$></td>
</tr>

<$endloop$>
  </table>
<$else$>

<b>
Regular Search found no documents! </b>

<$endif$>

<br/><hr/><br/>

<h3> Modified Search for Type Document </h3>

 <$QueryText=dDocType <matches> `Document`“$>
<$ResultCount=100$>

<$SearchEngineName=”database”$>
<$executeService(”

GET_SEARCH_RESULTS“)$>
 <$if SearchResults$>
    <b> Found <$TotalRows$> Results </b> <br>
  <table border=”1″ width=”80%” align=”center”>
  <tr bgcolor=”#CCCCCC”>
     <td align=”center”> <b> Doc ID </b> </td>
     <td align=”center”> <b> Doc Title </b> </td>
     <td align=”center”> <b> Person Name </b> </td>
<td align=”center”> <b> Person Number </b> </td>
</tr>
  <$loop SearchResults$>

<tr>
<td
align=”center”>
         <a href=”<$HttpCgiPath$>?IdcService=DOC_INFO_BY_NAME&dDocName=<$dDocName$>” target=”new”>
          <$dDocName$></a>
</td>
<td>
<$dDocTitle$></td>
<td>
<$xpersonName$></td>
<td>
<$xpersonNumber$></td>
</tr>

<$endloop$>
  </table>
<$else$>

<b>
Modified Search found no documents! </b>

<$endif$>


Rodando este código no UCM, vemos 2 resultados de busca:

image

A primeira busca (padrão) localizou 19 documentos. A segunda busca, modificada com o parâmetro SearchEngineName=’database’ encontra 24 documentos, os 19 da outra busca e os 5 que criamos com o Fast Check-In.

Na minha aplicação Java, também executei as duas buscas, usando a API RIDC. Os resultados (naturalmente) foram os mesmos:

image

Como vimos, o Fast Check-In pode ser uma opção para inserir grandes volumes de conteúdo de forma muito rápida, mas a busca tem que ser feita com um parâmetro adicional.

Até a próxima!

[]’s

OBS: Para fazer checkin de conteúdo metadata-only, você precisa definir estes parâmetros no config.cfg e reiniciar o UCM:

createPrimaryMetaFile=true
AllowPrimaryMetaFile=true

[ATUALIZANDO…]

Para buscar os documentos pela interface do UCM, você também precisará setar o parâmetro que define o motor de busca a ser usado.

Uma forma simples de fazer isso é criar uma regra, e definir um Side Effect para esta regra:

image

Criei uma regra chamada “DocumentMetaOnlySearch”, que possui uma condição de ativação para “Search” (ou seja, só será executada em caso de uma busca). Como um Side Effect, estou mudando o engine de busca para Metadata Only.

Se quisermos, podemos definir quais campos o usuário irá selecionar na busca, ou podemos definir valores padrão (no meu caso, Content Type = Document e Security Group = Public):

image

Depois inserimos esta regra em um novo Perfil:

image

Para que o link de busca não apareça nas opções de Check-In, precisamos marcar a opção Restrict Personalization Links e definir a seguinte regra no campo “has script for the check-in link”: <%isLinkActive=0%>:

image

Podemos ver que esta opção agora aparece no menu Search, mas não no New Check-In:

image

Por fim, comparamos as duas buscas:

Standard Search com os parâmetros dDocType=Document e dSecurityGroup=Public:

image

Total: 12 resultados.

Busca Metadata-Only com os mesmos parâmetros definidos:

image

Total: 17 resultados.

This entry was posted in ECM, Oracle. Bookmark the permalink.

One Response to Fast Check-in com UCM 11g

  1. Pingback: WebCenter Content – Importação em Massa | Conteúdo à Brasileira

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s