Hei, viedään tätä eteenpäin kahdessa "säikeessä"

1) Katsotaan, löytyykö tarvetta asiakkaiden keskuudesta.

2) Käyn läpi tekniset vaihtoehdot/reunaehdot tuotekehityksemme kanssa.

Palaan asiaan, kun olemme saaneet tätä työstettyä.

Hei Elias,

Kiitos ideasta. En usko että koko asiakastietokantaa tullaan avaamaan ulospäin ainakaan ihan lähitulevaisuudessa. Pelkkä avaaminen ei noihin ongelmiin vielä suoraan toisi ratkaisua, vaan vaatisi myös tietorakenteen dokumentoinnin ja tukea ulospäin jotta kumppanit siitä hyötyisivät ja ymmärtäisivät. Samoin avaaminen asettaisi meille kehityksessä rajoitteita taaksepäin yhteensopivuuden kanssa; siinä missä tällä hetkellä pystymme takaamaan, että rajapintamuutokset jotka tehdään toimii taaksepäin, niin mikäli kantaan riippuisi suoraan muitakin toteutuksia kuin meidän oma, tulisi tietorakenteiden muuttaminen haasteellisemmaksi. Tällä hetkellä rakenne voi elää vapaammin kun pidämme huolen, että resurssit joita rajapinta tarjoaa eivät ulospäin muutu.

Netvisor on ns. single-tenant, jossa jokaista yritysympäristöä kohden on oma kantansa. Tämän lisäksi kuitenkin esim. käyttäjätiedot yms. ovat muualla, eivätkä tuolla avattavalla tietokantayhteydellä löytyisi, jolloin tietyltä osin homma jäisi torsoksi. Toisaalta jos olisi erillinen aggregaattidatakanta jonka avaisi ulospäin niin sitten voisi olla mahdollista, mutta rajoittaisiko tämä sitten liikaa kerta raakadataan ei pääsisi käsiksi?

Toinen vaihtoehto voisi olla miettiä esim. Jiralla olevan oman custom. hakukielen tekemistä. Jirassa voit tehdä tietyistä lähteistä itse vapaasti kyselyjä sen omalla JQL-syntaksilla ja avata nämä kyselyt rajapinnan (webhooks) kautta ulos.

Kiitos keskustelun avauksesta, hauskaa ideointia. Toistaiseksi näitä ei vielä sen vakavammin olla mietitty ja tällä hetkellä keskitymme rajapinnan laajentamiseen ja miten saisimme sitä tehtyä ketterämmin mahdollisimman kattavaksi. Myös rajapinnan tietoturvapaneeli on tapetilla, siinä rajapinnan käyttöä voisi rajata yrityskohtaisesti resursseittain sekä luku/kirjoitus -moodilla.

Hei Arto,

Tietenkään pelkkä tietokannan avaaminen ei ratkaisisi viestissäni mainittuja ongelmia, vaan se edellyttäisi asiakaspuolelta myös kannan rakenteen tuntemista ja SQL- ja tietokantayhteysosaamista. Tarkoitukseni oli vain nostaa esiin asiakaskunnastanne Communityyn julkaistuja tiedonsaantitarpeita ja -ongelmia, jotka olisi mahdollista ratkaista, mikäli asiakkaalla olisi pääsy kantaan. Community kuitenkin on varmasti vain jäävuoren huippu. Valtaosaa tietotarpeista on varmasti pinnan alla.

Kohderyhmä peilitietokannalle ovat pääasiassa keskisuuret ja sitä suuremmat sekä muuten tieto-orientoituneet yritykset, joiden raportointi on kehittynyt niin, etteivät järjestelmien vakioraportit enää riitä palvelemaan niiden tarpeita. Tällaisten yritysten raportointi on rakennettu niiden omista lähtökohdista tukemaan niiden omaa tapaa toimia. Peilikannan voisi perustaa lisäpalveluna niille, jotka sitä pyytävät. Single tenant -rakenne toimii tässä erinomaisesti, sillä jokaisessa kannassa on jo rakenteen puolesta ainoastaan kunkin asiakkaan omaa dataa. Visma voisi tarjota lisäpalveluina myös peilikannan hyödyntämiseen liittyviä palveluita, kuten kantayhteyksien tai SQL-kyselyiden rakentamista.

Netvisor-käyttäjätiedoille tuskin on kovin suurta tarvetta peilikannassa, koska se on tarkoitettu käyttäjäpuolelta ainoastaan tiedon lukemiseen (vrt. varsinaisen järjestelmän käyttö, jossa on tärkeää tietää mm. kuka minkäkin kirjauksen on tehnyt). Pelikannassa voisi näin ollen olla omat (asiakkaan päässä yhteiskäytössä olevat) käyttäjätunnuksensa. Tietoturvan varmistamiseksi voisi käyttää esimerkiksi SSL-sertifikaatteja tai sallittuja ip-osoitteita. Sallitut ip-osoitteet tosin eivät ideaalivaihtoehto, kun mietitään saas-mallin ydinajatusta saavutettavuudesta.

Mikäli Visma tarjoaisi lisäpalveluna tuotantokannan peilausta, ei se olisi vastuussa siitä, miten kantarakenteeseen tehdyt muutokset vaikuttaisivat peilikantaan yhteydessä oleviin applikaatioihin. Tietorakenteen dokumentointi toki helpottaa kannan lukemista, mutta mikäli taulut ja niiden sarakkeet on nimetty ymmärrettävästi, ei kannan opettelu vaadi tueksi erillistä dokumentaatiota.

JQL ei ole varsinainen tietokantakieli, eikä se mahdollista kovinkaan monipuolisten kyselyjen tekemistä, joten sillä ei oikein voi korvata peilikantaa.