Follow Us on Twitter

Integreren met Webcenter Content

Gepubliceerd in

Oktober 2012 - Een vaak terugkerend thema in organisaties is “Content”. Hiermee wordt in de praktijk de invulling van een stuk software of website bedoeld. Vaak zijn dit gegevens uit een database gecombineerd met foto’s, filmpjes en documenten. Voor alles wat minder handig in een database is op te slaan heeft Oracle “Webcenter Content” (voorheen UCM). Dit is een zeer krachtig product dat niet alleen de opslag verzorgt, maar ook dingen zoals indexatie, versionering, groepering, conversies en beveiliging. Daarnaast bevat Webcenter Content een krachtige zoekmachine en een eigen querytaal om complexe zoekopdrachten uit te voeren.

Aangezien het product gepositioneerd is in de “Fusion Middleware” stack is het niet alleen de bedoeling om content op te slaan. De content die beschikbaar is in “Webcenter Content” moet namelijk te integreren zijn met verschillende andere producten uit de eerdergenoemde stack. De voornaamste integratiemethoden zijn de SOAP-service, de “Remote Intradoc Client“ en de “Document Service” taskflow.

De SOAP-service can d.m.v. een WSDL geconsumeerd worden door vele clients. Daarnaast kan je eventueel je eigen service creëren door middel van de Remote Intradoc Client (afgekort RIDC) API. Deze RIDC is een API welke voornamelijk gebruikt kan worden om op Content Server taken uit te voeren van een afstand zoals het zoeken van documenten of het uploaden van nieuwe documenten. Als laatste hebben we de “Document Service” taskflow die het mogelijk maakt om binnen ADF-applicaties content uit “Webcenter Content” beschikbaar te maken.

In dit Whitebook nemen we 2 van deze integratiemogelijkheden nader onder de loep, namelijk de RIDC API en een onderdeel uit de “Document Service” taskflow, de “Content Presenter”. Het zal duidelijk worden wanneer men welke van deze 2 services kan gebruiken, of wanneer ze te combineren zijn. Maar eerst zal uitgelegd worden hoe beide services geconfigureerd kunnen worden.

Verplichte configuratie

Voordat men de RIDC API of de “Content Presenter” kan gebruiken moet men nog de socket configureren waarover de communicatie met de content server kan plaatsvinden. Standaard is er geen socket geconfigureerd. Aangezien beiden werken d.m.v. deze socket zal er ingelogd moeten worden op de Enterprise Manager. (http://uwserver:7001/em) Vanuit hier gebruikt u de treeview om te navigeren naar het Content Management item zoals u op de onderstaande afbeelding kunt zien.

Nadat men via het menu op de “Configuration page” aangeland is kan de Intradoc serverpoort ingesteld worden. Gebruik bijvoorbeeld 4444 als poortnummer. Vergeet daarna vooral niet om in het IP-adres filter toegestane adressen in te vullen. Men kan ook een wildcard om alle adressen toe te staan gebruiken. (*.*.*.*)

Instellingen intradoc server

Als men de wijzigingen op heeft geslagen zal de content server opnieuw gestart moeten worden voordat deze wijzigingen actief worden.

RIDC

Om met RIDC aan de slag te kunnen zal men eerst de library moeten downloaden vanaf de Oracle OTN Website. De download kan gevonden worden tussen de “Individual Component Downloads” van "Webcenter Content". De JAR-bestanden uit deze download voegt men als library toe aan het betreffende JDeveloper project.

Om met documenten te mogen werken zal er eerst een IDC client aangemaakt moeten worden. Deze client maakt een connectie met de Content Server over de eerder geconfigureerde socket. Onderstaande code geeft een voorbeeld:

 public static IdcClient getClient() throws IdcClientException {
   // create the manager
   IdcClientManager manager = new IdcClientManager();

   // build a client that will communicate using the intradoc protocol
   IdcClient idcClient = manager.createClient(CONNECTION_PROTOCOL+"://"+UCM_HOST+":"+UCM_PORT);
   
   return idcClient;
 }

Naast een verbinding met de server is er ook een gebruiker benodigd voor autorisatie en authenticatie. Door middel van onderstaande code krijgt men een referentie naar een gebruiker die moet bestaan in de content server.

 public static IdcContext getUserContext(String username){
   IdcContext userContext = new IdcContext(username);
   
   return userContext;
 }

Doorzoeken van de contentserver

Het startpunt van een RIDC aanroep is vaak de “Binder”. Aan deze binder worden parameters meegegeven die bijvoorbeeld aangeven dat men wil zoeken naar documenten, waaraan deze documenten moeten voldoen en hoeveel resultaten er geretourneerd mogen worden. Na het uitvoeren kan men een “ResultSet” opvragen met de gevonden documenten. Hieronder een voorbeeld.

public List findByProject(String projectid)  {
   IdcClient idcClient;
   List projectFiles = new ArrayList();

   try {
     idcClient = ConnectionHelper.getClient(); 
     DataBinder binder = idcClient.createBinder();
     // populate the binder with the parameters
     binder.putLocal ("IdcService", "GET_SEARCH_RESULTS");
     binder.putLocal ("QueryText", "xxProjectCode  `"+projectid+"`");
     binder.putLocal ("ResultCount", "20");
     
     // execute the request
     ServiceResponse response = idcClient.sendRequest (ConnectionHelper.getUserContext(), binder);
     // get the binder
     DataBinder resultBinder = response.getResponseAsBinder ();
     DataResultSet resultSet = resultBinder.getResultSet ("SearchResults");
     
     // loop over the results
     for (DataObject dataObject : resultSet.getRows ()) {
       ProjectFile pfile = new ProjectFile(dataObject);   
       projectFiles.add(pfile);        
       
     }
   } catch (IdcClientException e) {
     e.printStackTrace();
   }
   return projectFiles;
 
}

Een punt van aandacht is de regel:

binder.putLocal ("QueryText", "xxProjectCode  `"+projectid+"`");

Hiermee wordt expliciet gezocht op een stuk metadata van een document. In dit geval de projectcode welke als metadata is toegevoegd aan het document (hoe men deze metadata configureert is buiten de scope van dit document). Deze query is exact hetzelfde als de query taal die binnen “Webcenter Content” wordt gebruikt om naar documenten te zoeken. Men kan via de console van de content server complexe queries samenstellen. Een tip is om een complexe query eerst aan te maken in de content server en deze dan als startpunt in de Java-code te gebruiken. Vanuit de Java-code kan deze dan geparameteriseerd worden.

Inchecken van documenten

Voor het inchecken wordt wederom een “Binder” aangemaakt om zaken zoals de titel, documenttype en beveliging vast te leggen. Het bestand dat een document bevat wordt daarna samen met deze “Binder” naar de content server gezonden. Een voorbeeld:

 public void checkIn(File file, String title, String name, String docType, String securityGroup, String projectcode)  {
   // create request
   IdcClient idcClient;

   try {
     idcClient = ConnectionHelper.getClient();
     DataBinder binder = idcClient.createBinder();
     binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL");

     // get the binder
     binder.putLocal ("dDocTitle" , title);
     binder.putLocal ("dDocName", name);
     binder.putLocal("xxProjectCode", projectcode);
     binder.putLocal("xProfileTrigger", "Controlled Document");
     binder.putLocal ("dDocType", docType);
     binder.putLocal ("dSecurityGroup", securityGroup);

     // add a file
     binder.addFile ("primaryFile", file);

     // checkin the file
     idcClient.sendRequest (ConnectionHelper.getUserContext("sysadmin"), binder);
   } catch (IdcClientException e) {
     e.printStackTrace();
   } catch (IOException e) {
     e.printStackTrace();
   }

 }

Configuratie voor een content presenter

Voordat een Content Presenter gemaakt kan worden moet er een definitie voor de content die men wil weergeven in de presenter gemaakt worden. Hiervoor wordt Oracle Site Studio gebruikt. Wanneer men bijvoorbeeld een afbeelding wil weergeven in een content presenter en men wil daarnaast ook de titel en een omschrijving kunnen tonen dan kan in Site Studio hiervoor een definitie aangemaakt worden. In deze definitie wordt verwezen naar documenten uit de content server en hun metadata.

Hoe men deze definities kan aanmaken en klaarzetten voor gebruik is buiten de scope van dit Whitebook. Desalniettemin is er een goede tutorial te vinden op “Yannick Ongena’s Webcenter en Enterprise 2.0 Blog” waarbij men aan de hand wordt genomen bij het maken van content presenters van begin tot eind. Op dit blog leest men ook hoe de content presenters zelf aangemaakt worden.

Wat moet men nog meer weten over content presenters

Een Content Presenter weergave wordt gedefinieerd in een ADF “Page Fragment”. Over het algemeen kunnen deze fragments hun eigen “ADF Page Definition” bevatten met bindings naar datacontrols en dergelijke. Voor Content Presenters is dit niet het geval. Men kan in JDeveloper voor een Content Presenter gewoon een page definition aanmaken maar bij het uploaden naar de portal wordt deze niet meegenomen wat resulteert in een runtime fout. Het is daarom lastig om content presenters te verrijken met informatie uit andere bronnen dan Webcenter Content. De manier om het gewenste effect toch te bereiken is door middel van managed beans. Men kan namelijk op de pagina waarin de content presenter geïntegreerd wordt een managed bean declareren en vullen. Vanuit de content presenter kan dezelfde bean aangeroepen worden. Let op dat hiermee wel een afhankelijkheid tussen de content presenter en de pagina gecreeerd wordt tenzij een session bean gebruikt wordt.

RIDC en de “Content Presenter”, wat kunnen ze en wanneer te gebruiken?

Belangrijk om te weten is dat de RIDC API uitermate geschikt is om documenten toe te voegen aan de content server en om te zoeken naar documenten in de content server. Zoeken in de content server kan door een zoekopdracht te schrijven in een querytaal die specifiek in de content server werkt en deze mee te geven dmv de API.

De “content presenter” wordt zoals de naam al suggereert vooral gebruikt om de documenten weer te geven. Hiermee wordt niet alleen een simpele lijst van documenten en hun typen bedoeld. De kracht van de “content presenter” zit hem vooral in het feit dat deze de inhoud van deze documenten kan weergeven. Bevat het bericht HTML-opmaak dan zal deze opmaak bijvoorbeeld netjes getoond worden in de webbrowser. Mocht de presenter niet standaard raad weten met een documenttype zoals bijvoorbeeld een filmpje, dan integreert men bijvoorbeeld zelf code in de content presenter om een filmpje te tonen. Ook met de “Content Presenter” kunnen complexe queries geschreven worden om documenten in de content server te zoeken en door middel van de presenter te tonen.

De keuze voor het gebruik van van de RIDC API of de “Content Presenter” is afhankelijk van 3 vragen. Namelijk:

1. Wilt u de inhoud van het document direct kunnen tonen in uw webapplicatie?
De RIDC API biedt geen handvat om documenten te tonen terwijl dit juist de kracht van de “Content Presenter” is. Mocht u toch de inhoud willen tonen en zit u vast aan de RIDC API dan zult u zelf code moeten schrijven om de documenten weer te geven.

2. Moet u documenten kunnen toevoegen vanuit uw webapplicatie? (inchecken)
Met de presenter kunt u alleen documenten zoeken en weergeven. De presenter biedt niet direct de functionaliteit om documenten te uploaden, terwijl de RIDC API hier uitermate geschikt voor is. Webcenter zelf bezit wel degelijk de mogelijkheid om documenten in te checken in Webcenter Content. Hiervoor worden de check-in schermen van Oracle Site Studio gebruikt omdat deze de definities bevat voor de content die door de “Content Presenter” gebruikt wordt om documenten te tonen. Helaas zijn de Site Studio schermen vaak niet gebruikersvriendelijk genoeg om deze door de gewone applicatiegebruiker te laten gebruiken. Vaak wordt dan een eigen gebruikersvriendelijk ADF-scherm gemaakt welke middels RIDC een bestand kan uploaden met alle bijbehorende metadata.

3. Gebruikt u Webcenter?
De “Content Presenter” is alleen beschikbaar in de Webcenter producten zoals “Webcenter Portal” en “Webcenter Spaces”. Binnen deze producten is de presenter dan ook meteen 1 van de meest gebruikte en krachtigste mechanismen. Gebruikt u geen Webcenter dan is men aangewezen op de RIDC api of de SOAP service.

Zoals u wellicht al opmerkt na het lezen van de bovenstaande punten hebben beide services hun specifieke sterke punten. Er is dan ook niets mis mee om deze services te combineren om te kunnen profiteren van al deze punten. In een ideale opzet gebruikt men dan de RIDC API om bestanden gebruikersvriendelijk in te checken in de content server. Voor het weergeven kan dan de Content Presenter gebruikt worden.

Conclusie

In dit Whitebook heeft u kunnen lezen over een tweetal integratiemogelijkheden met Webcenter Content. Er is uiteengezet waar de kracht van beide services ligt en hoe deze benut kan worden. In de praktijk is gebleken dat het beste resultaat bereikt wordt wanneer beide services gecombineerd worden. Om aan de slag te kunnen met de RIDC API hoeft u maar weinig te configureren. De content presenter daarentegen vergt een aantal stappen die u moet doorlopen alvorens u daadwerkelijk de presenters kunt implementeren. Het kan af en toe moeilijk zijn om te doorgronden waar al deze stappen voor nodig zijn en wellicht kan Oracle in de toekomst de configuratie wat makkelijker maken. Het staat hoe dan ook buiten kijf dat wanneer u de Content Presenter doorgrond heeft deze een onmiskenbare toegevoegde waarde voor Webcenter biedt.

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.