Mahdollisuus toteuttaa räätälöityjä ratkaisuja SharePointin päälle on ollut yksi SharePointin myyntivaltteja: jos valmistoiminnallisuus ei sellaisenaan ole riittävä, on toiminnallisuutta voitu usein laajentaa hyvin vapaasti haluttuun suuntaan.

Suomessa SharePoint-osaaminen on Microsoftinkin mukaan maailmanlaajuisesti mitattuna korkeatasoista, mutta SharePoint-räätälöinti ei siitä huolimatta ole aina täysin ongelmatonta. Väärin tehdyt, etenkin erityisen syvälliset, räätälöinnit saattavat hankaloittaa liiaksi SharePoint-versiopäivitystä, ja väärin toteutettu palvelinpään ohjelmakoodi voi pahimmillaan aiheuttaa jopa käyttökatkoja SharePoint-ympäristössä.

Viime syksynä Microsoftin räätälöintiviesti kääntyikin sitten päälaelleen. Tuotteen omistaja Jeff Teper ilmoitti, että SharePointia ei pitäisi räätälöidä, tai jos räätälöidään, se tulisi tehdä Apps-mallin mukaisesti. Myös Las Vegasissa pidetyssä SharePoint Conferencessa perinteiset kehitysmenetelmät vaiettiin kuoliaaksi, mikä osaltaan vahvisti viestiä. Seurauksena SharePoint-kehittäjäpiireissä aamukahvit taisivat tulla ulos useammastakin nenästä. Eikö räätälöintejä enää tueta?

Kyllä tuetaan: Sittemmin viestiin on tullut mukaan enemmän sävyjä, ja viimeksi maaliskuussa Microsoftin TechDays 2013-tapahtumassa Vesa Juvonen ja Jaakko Nikko pitivätkin ansiokkaan esityksen SharePoint 2013 –räätälöintisuosituksista. Tulkitsin virallisen viestin olevan ytimeltään seuraavan: SharePoint 2013 -versiosta alkaen kehitys siirtyy kohti vähemmän ja kevyemmin räätälöityjä ympäristöjä, mutta maailma ei muutu yhdessä yössä. 

Vesan ja Jaakon sessio on nähtävillä YouTubessa osoitteessa http://youtu.be/kXR0S0rGHqQ. Suosittelen esityksen katsomista alusta loppuun, koska tunnin investoinnilla säästät monta ratkaisujen toteutuksiin liittyvää kysymystä. Mielestäni tallenne on lähes pakollista katsottavaa kenelle tahansa SharePoint-ratkaisujen parissa työskentelevälle. Räätälöintikeskustelussa ei mielestäni kuitenkaan ole kovin laajasti pureuduttu siihen miksi räätälöintikysymys ei ole niin mustavalkoinen. Tätä pyrin avaamaan seuraavissa kohdissa.

(Huomioidaan muuten, että kirjoittaessani omaa juttuani huomasin atBusineksen Juha Vitikan pohtineen samaa ongelmaa  kanssani samanaikaisesti: http://www.atbusiness.com/Blogi/Intranet-SharePointilla-valmistoimintona-konfiguroimalla-raatalointina-vai-jotain-muuta).

Mikä lasketaan räätälöinniksi?

Jotta voidaan keskustella räätälöinneistä, tulee ensin määritellä mitä SharePoint-räätälöinti on. Onko räätälöinti vain ohjelmakoodia? Entä WSP-paketin (MOSS 2007-versiosta lähtien käytetty tapa paketoida konfiguraatioita ja räätälöintejä automaattisesti asentuviksi) mukana asennettu valmiswebosan konfiguraatiotiedosto? Kuinka pitäisi suhtautua metatietokenttään, joka viedään automaattisesti WSP-paketin kautta, mutta jonka voisi toisaalta konfiguroida käsin käyttöliittymältä?

Mielipiteitä asiasta riittää, mutta harva niistä on erityisen selkeä. Pääsyyllinen sekavaan tilanteeseen on SharePointin kahtiajakoisuus tuote- ja alustanäkökulmien välillä: SharePointin valmistoimintoja voidaan käyttää konfiguroimalla tuotteen tapaan, mutta käytännössä ratkaisut on useimmiten rakennettu koostamalla valmistoimintoja kokonaisratkaisuksi kehitysalustan tapaan. Toisaalta samojakin konfiguraatioita (kuten uudet metatietokentät ja sisältölajit) voidaan toteuttaa joko käyttöliittymän kautta, tai asentamalla WSP-paketteja. Asiaa ei  auta sekään, että myöskään Microsoft ei ole esittänyt yhtä selkeää määritelmää sille, mikä pitäisi laskea räätälöinniksi.

Käsittelimme Tomi Tavelan kanssa räätälöinnin määritelmää 2010-maailmassa viime vuoden maaliskuussa artikkelisarjassa ”SharePointin räätälöinti kuumentaa tunteita”. Myönnän, että analyysini jäi silloin puolitiehen, sillä todellisuudessa lähtökohdaksi pitää ottaa käyttäjäorganisaation tarpeet sovelluksen elinkaaren hallinnan näkökulmasta. Väitänkin, että ratkaisu on räätälöity aina, kun sen ylläpito, tai vieminen uuteen SharePoint-versioon edellyttää sovelluskehittäjän työpanosta. Kehittäjällä tarkoitan tässä myös web designereita.

Näin määriteltynä voidaan aidosti arvioida ratkaisua ylläpidon ja migraatioiden kannalta. Toisaalta sen perusteella huomataan, että lähes kakki laajat ympäristöt ovat räätälöityjä: Yleensä vähintään käyttöliittymään on tehty asiakaskohtaisia muutoksia, ja ulkoasu vaatii muutoksia viimeistään versionvaihdossa riippumatta siitä, onko räätälöinti tehty SharePoint Designerilla, SharePoint 2013:n design managerilla, tai asennettu WSP-pakettien kautta. Samoin kaikki sellaiset ympäristöt, joissa konfiguraatiot (kuten metatiedot) asennetaan järjestelmään automatisoidusti WSP-paketeilla, ovat räätälöityjä. Riippumatta siis siitä, onko paketissa riviäkään ohjelmakoodia.

Milloin ja miksi räätälöintejä voidaan tarvita jatkossa? Seuraavassa muutamia esimerkkejä.

Asiakaskohtainen ulkoasu ja responsiivinen taitto

SharePointin version vaihtuessa käyttöön tulee uusia toimintoja, ja niiden mukana uusia käyttöliittymäelementtejä. Jos SharePointissa on räätälöity ulkoasu, uudet toiminnot edellyttävät uudet css-määritykset. Kun siis SharePointin versio vaihtuu, ja uudet ominaisuudet halutaan ottaa käyttöön, joudutaan vähintäänkin uusille ominaisuuksille toteuttamaan uudet css-määritykset, vaikka master-sivu olisi jätetty rauhaan.

SharePointin valmiskäyttöliittymä ei myöskään ole responsiivinen. Sen asettelu ei siis mukaudu käytetyn ruudun kokoon. Jos SharePoint-sivustoa siis halutaan optimoida erilaisille päätelaitteille, tarvitaan muokkauksia master-sivuun, css-määrityksiin ja sivupohjiin – siis räätälöintiä.

Versiopäivityksen kestävän ulkoasun voi tehdä teemoilla. Teemalla voidaan vaihtaa taustakuva, fontit ja värimaailma halutunlaiseksi. Jos kevyempi ulkoasun muokkaus riittää, suosittelen ehdottomasti käyttämään teemoja, varsinkin pilvessä. SharePoint Onlinessa teemojen merkitys korostuu, sillä versiopäivityksiä tulee paikallista ympäristöä useammin, ja Microsoft varaa oikeuden muuttaa master-sivujaan. Responsiivista taittoa teemoilla ei kuitenkaan voi tehdä; toisaalta palvelu voi päivitysten kautta alkaa tukemaan responsiivisuutta paremmin.

Appsit eivät vielä sovi kaikkeen

Appsit ovat uusi suositeltu menetelmä toteuttaa asiakasratkaisuja, mutta tällä hetkellä niillä ei voi tehdä kaikkea mitä perinteisesti on haluttu tehdä. Appsit eivät sovi kaikkeen esimerkiksi seuraavista syistä:

  1. Appsit eivät toimi julkisilla www-sivustoilla. Julkiset www-palvelut tarvitsevat siis perinteisiä palvelinpään keinoja tuottaa dynaamista sisältöä.
  2. Sivustopohja ei voi nykyisenlaisena olla mielekkäästi toteutettu appsina. Jos halutaan tehdä sivustopohjia, tulee pohjat joko tehdä web template –tekniikalla WSP-pakettiin, tai tallentaa käyttöliittymältä mallina. Julkaisusivustoja ei kuitenkaan voi tallentaa mallina, joten nämä sivustopohjat on pakko tehdä WSP-paketteina.
  3. Javascript-rajapinnoilla ei voi vielä tehdä ihan kaikkea. Javascript-koodi suoritetaan käyttäjän työasemalla, eikä esimerkiksi dokumentin metatiedon täyttäminen automaattisesti dokumenttikirjastossa onnistu järkevästi ilman palvelinpään tapahtumankäsittelijää. Omat ongelmansa tulee myös siitä, että javascript-koodi ajetaan SharePoint-hosted appsissa aina loppukäyttäjän oikeuksilla, eikä voida hyödyntää erillisiä sovelluksen oikeuksia. Jos sovellus taas ei ole toteutettu SharePointiin, voi yksinkertainen tarve toteuttaa hyvin monimutkaisen arkkitehtuurin.
  4. Apps-menetelmällä on erittäin työlästä asentaa esimerkiksi metatietomäärityksiä sivustoille. Vaikka se teoriassa onnistuukin, kaikki on ohjelmoitava itse javascriptillä. Tämä taas on toiminut WSP-pakettien kautta XML-pohjaisesti jo vuosia, ja menetelmä on luotettava. Toivon todella, että tämä rajoite saadaan poistumaan jossain vaiheessa, mutta toisaalta tällöin Apps-mallinen sovelluspaketti alkaa muistuttaa jo WSP-pakettia…

Toistettavat asennukset ja versionhallinta vaativat WSP-paketteja

Vaikka ratkaisu ei edellyttäisikään ohjelmakoodia, ilman WSP-pakettia ei käytännössä saada aikaiseksi automaattisia, toistettavia asennuksia (ellei tietysti pärjätä pelkillä Apps-mallisilla ratkaisuilla).

Perinteisiä WSP-paketteja tarvitaan nimittäin silloin, kun ratkaisu tulee pystyä viemään toistettavasti useisiin ympäristöihin, kuten kehitys-, testi- ja tuotantoympäristöihin, automatisoidusti ja hallitusti. On totta, että teoriassa WSP-paketin voisi korvata Apps-malliin tai PowerShelliin pohjautuvalla provisioinnilla, mutta onko käytännöllistä toteuttaa itse rinnakkainen provisiointimekanismi, kun luotettava ratkaisu on jo olemassa?

Käyttöliittymästä tehty ratkaisu ei myöskään sisällä kovin pitkälle vietyä versionhallintaa. Toki yksittäisten tiedostojen versiointi onnistuu SharePoint-kirjastojen mekanismeilla, mutta ainoa tapa versioida kokonainen ratkaisu kerralla olisi versioida tietokantakopioita. Tästä puolestaan seuraa joukko uusia ongelmia, lähtien jo kymmenien tai satojen gigatavujen tietokantojen tallentamisesta ja hallinnasta.

Miksi asennuksien sitten pitäisi olla toistettavia ja ratkaisun toteutuksen versioitu? Toistettavat (=minimaalisesti manuaalisia vaiheita sisältävät) asennukset helpottavat asennuksia käyttöönotossa sekä ylläpidossa. Automaattisesti asennettava ratkaisu vähentää työtä ja etenkin inhimillisiä virheitä asennusten yhteydessä. Jos laaja ratkaisu rakennetaan pelkästään käsin konfiguroimalla (siis ilman WSP-paketteja ja skriptausta), ja organisaatiolla on ylläpidettävänä tuotannon lisäksi esimerkiksi testiympäristö, ylläpidon vaiva kasvaa liiaksi. Jossain elinkaaren vaiheessa ympäristöt eivät enää vastaa toisiaan, eikä kukaan tiedä tarkkaan, missä erot ovat. Ja sitten voi kysyä mitä merkitystä tällaisella testiympäristöllä enää on?

Versionhallinta yhdessä automatisoitujen asennusten kanssa puolestaan mahdollistaa ongelmien luotettavan selvittämisen, ja ratkaisuun liittyvien tuotosten jakamisen tiimin useamman henkilön kanssa. Toki useampi kehittäjä voi konfiguroida ratkaisua yhteen ympäristöön yhtä aikaa, mutta tällöin on huomioitava, että sama ratkaisu tulee manuaalisesti konfiguroida myös tuotantoon.

Miten eteenpäin?

Edellä oli listattuna muutamia keskeisiä syitä siihen, miksi useimmissa ympäristöissä tullaan vielä tarvitsemaan räätälöintejä. Ryöpytyksestäni huolimatta kenenkään ei pidä kuvitella, että asioita tehdään jatkossa niin kuin ennenkin. Päinvastoin! Kevyempiä ratkaisumalleja on aina ollut hyvä hyödyntää, ja jatkossa entistä enemmän.

Tässä muutamia ohjeita SharePoint-projekteihin:

  • Kyseenalaista räätälöidyn toiminnallisuuden tarve entistäkin vahvemmin, mutta älä käyttökokemuksen kustannuksella.
  • Kyseenalaista palvelinpään ratkaisun tarve: .NET-koodi, joka suoritetaan SharePoint-palvelimen sisällä, on edelleen toisinaan välttämätöntä, mutta ei tulevaisuuden kehityssuunta. Tällainen sovelluskoodi ei myöskään siirry pilveen muuten kuin kirjoittamalla se kokonaan uusiksi.
  • Toisaalta hyväksy, että aivan kaikkea ei voi tehdä ilman räätälöintiä: WSP-paketti on useimmissa tapauksissa edelleen ystäväsi.

Edellisestä seuraa, että jokaisen ratkaisun osalta tuleekin jatkossa pohtia:

  • Onko kyseinen ominaisuus välttämätön?
  • Voiko riittävän ratkaisun toteuttaa pelkästään konfiguroimalla (ja skriptaamalla konfiguraatiot) SharePoint-sisältötietokantaan?
  • Voiko riittävän ratkaisun toteuttaa hyödyntäen SharePointin Enterprise-lisenssin palveluita, kuten hakupohjaiset webosat, Excel Services, Access Services, työnkulut?
  • Voiko ratkaisun toteuttaa Apps-mallilla?
  • Voiko ratkaisun muuten toteuttaa ilman palvelinkoodia javascript-pohjaisesti?

Kysymysten merkitys korostuu etenkin pilviratkaisuissa, missä räätälöintiin on vähemmän mahdollisuuksia. Pilvessä on erityisesti huomioitava mainitsemani ulkoasuräätälöintiin liittyvät riskit, ja se, että .NET-koodia pilvessä ei tule ajaa lainkaan.

Jatkossa toimittajien vastuulla on entistä enemmän edistää asiakkaiden tietoisuutta SharePointin valmistoimintojen mahdollisuuksista, kun asiakkaan osuus yhtälössä on taas keskittyä räätälöintitarpeissaan olennaiseen: Käyttökokemuksen parantamiseen ja keskeisiin automatisointeihin. Jotta räätälöintejä voidaan vähentää, SharePoint täytyy jatkossa hyväksyä enemmän (mutta ei yksinomaan) tuotteena, mikä edellyttää käyttäjiltä myös mukautumista tuotteen sielunelämään.

Muistetaan siis, että juna on lähtenyt liikkeelle asemalta, ja päätyy oikealle asemalle. Emme vain ole vielä perillä.

Kiinnostaako uusi SharePoint?

Asiantuntijamme ovat julkaisseet blogissa syksyn aikana useita uuden SharePointin ominaisuuksia esitteleviä kirjoituksia.

Lisätietoja Sinisen Meteoriitin palveluista

Kirjoittaja: Jarno Leikas

Tietoa kirjoittajasta