Rabobank Nederland

Januari 2013 – December 2013 | Rabobank Nederland via HeadFirst

Sharepoint developer

Bij Rabobank Nederland werd een nieuw CLC proces geïmplementeerd. De hierbij gedefinieerde efficiencydoelstelling was het vervallen van de functie ‘Web-ondersteuner’ Web management. Deze doelstelling werd bereikt en het RaboWeb werd gemigreerd van Tridion naar SharePoint.

Samengevat werd het content beheer gedecentraliseerd:

  • door Tridion te vervangen door SharePoint 2010,
  • ‘as-is’-migratie versus ‘zo min mogelijk maatwerk’ in SharePoint 2010,
  • voor 40.000 lezers,
  • 800 schrijvers/publicisten,
  • en ca. 10 FTE functioneel beheer (FS en Support).

Anita was verantwoordelijk voor het maken van technische (deel-) ontwerpen, de migratie, de ontsluiting van informatie uit verschillende systemen en het ontwikkelen van diverse maatwerkonderdelen op het SharePoint platform.

Het content life cycle (CLC) proces bij Rabobank Nederland had de volgende stappen:

  1. Het creëren van content (co-creatie),
  2. het publiceren, raadplegen van een gepubliceerde pagina,
  3. het beoordelen van de content middels waarderen en het geven van feedback,
  4. het optimaliseren van content,
  5. het archiveren van content (depubliceren) en
  6. het verwijderen/archiveren van content.

Anita is werkte als ontwikkelaar in dit project uitgebreid met de volgende onderdelen:

  • Velden en contenttypes, gedistribueerd via de contenttype hub.
  • Diverse page layouts  en webtemplates. De page layouts  maakten gebruik van verschillende cacheprofielen.
  • Custom Actions: het verbergen van standaard ribbon knoppen (stijlknoppen), het tonen van standaard ribbon buttons op een andere plaats en het toevoegen van custom ribbon knoppen. Een voorbeeld van het tonen van een standaard ribbon knop op een andere plaats is de Versiegeschiedenisknop. Deze wordt door SharePoint getoond in de Paginageschiedenis. Praktischer is om deze knop weer te geven als de pagina wordt bewerkt.
  • Het automatisch schalen van afbeeldingen, om te voorkomen dat er in omvang grote afbeeldingen op een pagina worden weergegeven.
  • Hyperlinks die verwijzen naar een hoofdstuk/paragraaf binnen een andere pagina. Dit is bijvoorbeeld gewenst bij lange pagina’s, om eenvoudige te kunnen deeplinken naar het gewenste hoofdstuk.
  • Nieuws webparts op basis van het standaard Content Query webpart.
  • Banner webpart met verschillende selectiemogelijkheden: een afbeelding, zichtbare tekst, positie van de tekst in het webpart en een url, waarvan de pagina opent als er op de banner wordt geklikt.
  • Contactformulier waarmee bezoekers een vraag kunnen stellen. De gegevens worden ingelezen in een achterliggend systeem, zodat de vraag en afhandeling kunnen worden geregistreerd en verwerkt.
  • Aanpassing van de goedkeuringsstap in het publicatieproces, zodat goedkeuring van content wordt gebaseerd op custom gedefinieerde permissielevels. Op basis daarvan kan functioneel beheer zelf groepen definiëren om het goedkeuringsproces in te regelen.
  • Implementatie van de registratie van op welke pagina’s, welke documenten zijn gerefereerd en gepubliceerd. Bij het depubliceren van een pagina wordt deze registratie uiteraard bijgewerkt. Niet gebruikte documenten worden niet in de zoekmachine weergegeven, dat vervuiling van het systeem tegengaat.

De informatie uit verschillende systemen moest worden ontsloten. Dit werd gerealiseerd door:

  • Databases en web services vanuit een timerjob aan te roepen en de data geserialiseerd op te slaan in SharePoint lijsten. Webparts en webcontrols lezen de data uit deze lijsten middels handlers en laten de opgemaakte content zien.
  • Xml bestanden (output van een ander systeem) die in een SharePoint lijst zijn geplaatst vanuit een timerjob in te lezen. De inhoud van een xml bestand wordt op een gekoppelde pagina geplaatst en de pagina wordt gepubliceerd. Hierbij wordt gebruik gemaakt van de changelog van SharePoint, om te bepalen of de content op een pagina daadwerkelijk vervangen moet worden en of de pagina opnieuw gepubliceerd moet worden.

De structuur en content migratie van Tridion naar SharePoint 2010 was onderverdeeld in 3 stappen:

  1. Aanmaken structuur

De structuur werd op basis van de sitemap en siteindex uit Tridion gehaald en opgeslagen in een csv bestand. Hierin kun je handmatig aanpassingen doen in bijvoorbeeld de volgorde, je kunt aangeven welk type web of pagina er in SharePoint aangemaakt moet worden en je kunt onderdelen toevoegen of verwijderen.

  1. Migreren van documenten en afbeeldingen

Op basis van deze verrijkte csv, waar alle webs en pagina’s in staan, kun je bepalen welke resources (documenten en afbeeldingen) op de pagina’s moeten worden gebruikt. Deze worden uit Tridion gedownload en op de juiste plaats in SharePoint toegevoegd. Deze kennis wordt voor later gebruik opgeslagen in een csv bestand.

  1. Migreren van content

Om de content uit Tridion in SharePoint te plaatsen worden alle voorgaande bestanden gebruikt. Op deze manier worden pagina’s op basis van de aangegeven pagelayout en content type aangemaakt, de juiste resources gerefereerd op een pagina, kunnen links worden herschreven (ook over site collecties heen), en kun je webparts met de juiste instellingen en metadata toegevoegen aan de pagina.

Aantallen:

  • Er werden +/- 1.800 webs aangemaakt, gebaseerd op verschillende custom web templates, verdeeld over 10 sitecollecties.
  • Er werden +/- 12.000 resources toegevoegd.
  • Er werden +/- 7.000 pagina’s aangemaakt, gebaseerd op verschillende custom page layouts  en content types

Tijdens het migratieproces werd precies bijgehouden en opgeslagen welke onderdelen van Tridion waar in SharePoint werden geplaatst. Deze kennis wordt gebruikt in de redirect service om gebruikers, die na de migratie Tridion url’s in favorieten, documenten of emails hebben bewaard, om te leiden naar de overeenkomstige pagina in de nieuwe SharePointomgeving.

Deployment van de oplossingen werd geheel gescript met PowerShell.

SharePoint Server 2010, Visual Studio 2012/2010, Team Foundation Server, PowerShell, SPCAF, SharpLinter