ESTANDARDITZACIÓ I UNIFICACIÓ EN LA COMPARTICIÓ D’EVENTS D’AGENDA A L’AJUNTAMENT DE BARCELONA

Octavi Palau i Tarradas Índex

1 Abstrac6

2 Resum 7

3 Objectiu8

4 Introducció9 4.1 ASIA...... 10 4.1.1 Plantilles...... 10 4.1.2 Processos Batch...... 10 4.1.3 Serveis web...... 10 4.2 Plataformes intermèdies...... 11 4.2.1 Middleware...... 12 4.2.2 AsiaCache...... 12 4.2.3 Gestors de continguts...... 13 4.2.4 GuiaBCN...... 13 4.3 Clients finals...... 14 4.4 Visites...... 15 4.5 Arquitectura...... 15 4.6 Format de compartició...... 16 4.6.1 Serveis...... 16 4.6.2 Calendaris...... 17 4.7 Sincronització...... 17 4.8 Resum dels problemes actuals...... 17

2 Índex

5 Estudi de la solució i impacte 19 5.1 Estudi d’alternatives...... 19 5.2 Solució general...... 20 5.2.1 Ingesta...... 20 5.2.2 Aplanament de dades...... 21 5.2.2.1 Finestra d’aplanament...... 22 5.2.2.2 Control data modificacions...... 22 5.2.2.3 Manteniment funcionalitats actuals...... 22 5.2.3 Incorporació informació als serveis...... 23 5.3 Requeriments d’un acte/event...... 23 5.3.1 RFC5545...... 24 5.3.2 Horari d’un acte actual...... 24 5.3.2.1 Període...... 25 5.3.2.2 Dies...... 26 5.3.2.3 Dies obertura regulars...... 26 5.3.2.4 Dies exactes inclosos...... 26 5.3.2.5 Dies exactes exclosos...... 27 5.3.2.6 Dates relatives...... 27 5.3.2.7 Hores...... 28 5.3.3 Exemples d’horari...... 28 5.4 Integració part client...... 30 5.5 Implantació...... 31 5.5.1 Incorporació dins ASIA del nou mòdul...... 31 5.5.2 Adaptació serveis actuals...... 32 5.5.3 Revisió de l’arquitectura...... 33 5.5.3.1 Actes migrats...... 33 5.5.3.2 Clients migrats...... 33 5.5.4 Fi d’implantació...... 33 5.6 Sincronització...... 33 5.6.1 Serveis...... 33 5.6.2 Calendaris...... 34

3 Índex

6 Desenvolupament 35 6.1 Ingesta...... 35 6.1.1 Importació calendaris...... 35 6.1.2 Formularis web...... 35 6.2 Persistència d’actes...... 36 6.2.1 Model BBDD...... 38 6.2.2 Camps d’un acte dins RFC5545...... 38 6.3 Aplanament de dades...... 39 6.4 Creació serveis...... 40 6.4.1 Definició del Serveis web RESTful (API)...... 41 6.4.1.1 Mètodes GET implementats...... 42 6.4.1.2 Estructura URLs...... 43 6.4.1.3 Mètodes GET per paràmetres...... 43 6.4.1.4 URL SEO...... 45 6.5 Resum nous serveis...... 45 6.5.1 Llistats d’actes...... 45 6.5.2 Detall d’actes...... 45 6.5.3 Creació de calendaris...... 46 6.5.3.1 Funció...... 46 6.5.3.2 Nou servei calendari...... 46 6.6 Adaptació sistemes actuals...... 47 6.6.1 Serveis web ASIA...... 47 6.6.1.1 Llistat d’agenda...... 47 6.6.1.2 Detall d’agenda...... 52 6.6.2 Serveis GuiaBCN...... 53 6.6.2.1 Llistat d’agenda...... 53 6.6.2.2 Detall d’agenda...... 53 6.7 Altres...... 53 6.7.1 Control de modificacions...... 53

4 Índex

7 Anàlisi dels resultats obtinguts 55 7.1 Millora tècnica...... 55 7.2 Reducció costos...... 55

8 Conclusions 56

9 Línies de futur 57

10 Índex de figures 58

11 Bibliografia 59

12 Cost del projecte 62

13 Annex 63 13.1 Introducció...... 63 13.2 Propietats de l’event...... 63 13.2.1 Propietats requerides i d’una ocurrència...... 63 13.2.2 Propietats opcionals però només una ocurrència...... 64 13.2.3 Propietats opcionals però no haurien de tenir més d’una ocurrència 65 13.2.4 Propietats de final d’event...... 65 13.2.5 Propietats opcionals amb múltiple ocurrència...... 66 13.3 Components de recurrència...... 67 13.3.1 Regles de recurrència...... 67 13.3.2 Recurrència de dies i períodes...... 75 13.3.3 Dates d’excepció...... 76

5 Capítol 1

Abstrac

El document inclou l’estudi i la implementació d’un sistema centralitzat, en substitució de l’actual, per a la gestió d’events d’agenda, seguint l’especificació de la normativa RFC5545, amb l’objectiu, d’implantar un estàndard i oferir una base per la compartició de l’agenda de Barcelona a sites, aplicacions mòbils, xarxes socials i aplicacions clients. La solució que implementem treballa sobre tecnologia PHP.

6 Capítol 2

Resum

L’Ajuntament de Barcelona disposa d’una eina per a informar al ciutadà de l’agenda i dels equipaments de la ciutat. La gestió dels horaris es feta a mida segons les necessitats del client, concretament, del servei telefònic d’atenció al ciutadà. Amb el temps es van anar fent adaptacions per tal de compartir i publicar aquesta informació en sites i d’altres productes de dins i fora de l’Ajuntament. Actualment la compartició d’aquesta informació, al no seguir cap estàndard, és extremada- ment complexe i costosa, tan de desenvolupament, de manteniment i a nivell productiu. És per això que cal una solució per estandarditzar la compartició de l’agenda i eliminar totes les solucions intermèdies que s’han anat desenvolupant durant anys. La especificació RFC5545 juntament amb una adaptació poden solucionar aquest problema i fer desaparèixer la complexitat i el cost actual d’integració i de funcionament. Caldrà també que el sistema actual convisqui amb el nou durant el període transició sense que hi hagi afectació en cap dels seus serveis. En aquesta fase ja hauran d’estar disponibles les noves funcionalitats. Al final del document exposem les conclusions i les línies de futur.

7 Capítol 3

Objectiu

L’objectiu del projecte és implementar una solució software que permeti gestionar l’agenda orientada a la ciutadania de l’Ajuntament de Barcelona. La finalitat és la de posar la informació d’agenda a l’abast d’entitats i del ciutadà en un format estàndard, concretament seguint la normativa RFC5545. Cal que la definició dels horaris s’ajusti a les necessitats actuals, ja que alguns dels horaris dels actes de la ciutat es desvien dels formats estàndards existents. Caldrà també que el procés de migració sigui del sistema antic al nou sigui el menys traumàtic possible per al usuaris que gestiones els continguts i pels clients que l’exploten. El projecte pretén eliminar un conjunt de plataformes utilitzades per a donar el servei que hi havia fins ara. Així eliminaríem el cost que suposen i eliminaríem els retards que provocaven.

8 Capítol 4

Introducció

El sistema actual ASIA1 gestiona tots els actes i equipaments de l’Ajuntament de Barcelona i és el que centralitza la ingesta de continguts i la seva publicació i distribució per diferents canals. A partir d’aquest i mitjançant un conjunt de plataformes intermèdies s’informa al ciutadà via diferents webs i aplicacions mòbils. La necessitat d’aquestes plataformes neix amb l’objectiu d’assegurar els temps de resposta i evitar col·lapses en el sistema central ASIA. Bàsicament el que feien era replicar un subconjunt d’entitats en funció de cada client, per tal que preparessin els continguts obtinguts segons les seves necessitats. Aquesta replicació implica una desactualització de la informació i portava als administradors de l’eina a configurar programacions d’actualitzacions depenen de molts factors i acabava sent un mal de cap. Aquest risc és degut a que les consultes d’agenda són molt costoses en funció del tipus de consulta. El problema recau en el mètode de càlcul dels horaris, és a dir, en l’algorisme per calcular la celebració de cada acte. L’algorisme permet obtenir la data i hora de celebració d’un acte per un dia determinat, implicant que per al dia següent ens caldria una altre consulta. Depenen del nombre d’actes i de la finestra de dies podia resultar impossible, i per tant, obliga a les plataformes intermèdies a treballar amb finestres de dies petites. Degut a que la compartició de cada acte no inclou el seu horari, cal retornar la relació de les seves celebracions de forma separada la qual cosa complica la gestió per part dels client i en segon lloc, deixa als clients sense la possibilitat de calcular la celebració dels actes fora del període de la consulta. La compartició d’aquests horaris al ser un sistema propietari és incompatible amb entorns actuals, siguin mòbils, xarxes socials o eines de calendari. En el cas de solucions software a mida, la integració dels serveis ASIA és costosa ja que es desenvolupa en cada cas la part de consulta dels serveis. 1Eina de gestió d’Agenda i Equipaments de l’Ajuntament de Barcelona. Aplicació J2EE amb base de dades Oracle.

9 Capítol 4. Introducció

La ingesta també està lligada a la eina actual d’administració d’ASIA. Tans sols és possible per l’administració web en formularis html que ofereix l’aplicació ASIA. ASIA publica una sèrie de serveis web per a que els clients finals puguin consultar els seus continguts. En el punts següents els detallem.

4.1 ASIA

És l’aplicació J2EE actual que gestiona els actes i els equipaments de l’Ajuntament de Barcelona. El desenvolupament inicial és de l’any 2000 i ha anat sofrint tota mena de canvis.

4.1.1 Plantilles

Eina antiga que ofereix continguts en base a les cerques i les consultes que es fan de llistats i detall. Les plantilles inclouen la presentació final.

4.1.2 Processos Batch

Processos de gran càrrega que fam imatges de la base de dades per a que GuiaBCN pugui disposar dels continguts. La freqüència d’actualització en alguns casos és de l’ordre d’un dia.

4.1.3 Serveis web

Similar a una API, que funciona sobre HTTP i ofereix servei de cerca i consulta d’actes, equipaments, classificacions i d’altres. A continuació mostrem els serveis actuals.

Agenda Equipaments

Resum per Temes Resum per Temes Nou resum per Temes Resum per Districtes Resum per Districtes Llista EQ Llista AG Llista simple EQ Nova Llista AG Detall EQ Detall AG Detall simple EQ Detall simple AG Relacions entitat EQ

10 Capítol 4. Introducció

Dates AG Serveis Socials Data Esborrat

Figura 4.1 - Serveis web d’ASIA actuals

4.2 Plataformes intermèdies

Són aplicacions software que ofereixen els serveis d’agenda i equipaments a tercers per tal d’evitar la càrrega d’ASIA i també per formatar els continguts d’una manera idònia. A la figura següent es pot veure l’arquitectura actual amb les plataformes intermèdies, i que a continuació descrivim:

Figura 4.2 - Arquitectura actual Agenda i Equipaments de Barcelona

11 Capítol 4. Introducció

4.2.1 Middleware

Aplana els continguts i els deixa preparats per tot un seguit d’aplicacions mòbils. S’alimenta de la informació que serveix AsiaCache. Bàsicament realitza crides a les cerques preconstruides de llistats a AsiaCache i genera uns fitxers plans de dades per a farcir les bases de dades de les aplicacions mòbils.

4.2.2 AsiaCache

Sistema de consulta-resposta que emmagatzema per cada consulta la seva resposta. Actualitza la resposta en funció de la freqüència programada. Entre d’altres serveix al mòdul Middleware. És un clar exemple de la càrrega que suposa el càlcul d’agendes ja que cada una de les consultes prepara un llistat dels actes que es celebren per un dia en concret. Aquestes peticions a dia d’avui estan limitades a una finestra 90 dies des de el dia actual. La freqüència disminueix en funció del nombre de dies respecte al dia d’avui i per tant estan més desactualitzats. En les figures següents es mostra l’administració de l’eina, la primera el llistat de peticions i la segona la gestió de una de les peticions amb la seva programació.

Figura 4.3 - Exemple Administració AsiaCache

Gestiona peticions, a part pel middleware, amb gran volum de dades de resposta i de baixa actualització. Un exemple podrien ser cerques per actes o equipaments que donen servei a webs de campanya i que tenen una vigència en un període curt. Generalment els continguts resposta es processen amb algun CMS i posteriorment es serveixen al ciutadà.

12 Capítol 4. Introducció

4.2.3 Gestors de continguts

Tots lligats a no tenir mai la informació complerta dels horaris i més desactualitzats que el mòdul de GuiaBCN. Utilitzen tant els serveis XML d’ASIA, API de GuiaBCN, AsiaCache i d’altres. La solució ha de poder oferir l’agenda a tots ells en diferents formats, llistats propietaris, calendaris o solucions amb les dues. Un dels objectius del projecte és oferir els horaris per tal que aquests, mitjançant llibreria, puguin gestionar les celebracions dels actes per ells mateixos i oferir al ciutadà en el format que considerin oportú en cada cas. En la actualitat els diferents gestors de contingut clients per plataforma són:

• Vignette • Drupal • Wordpress • Aplicacions en ruby, python, perl, java i php.

4.2.4 GuiaBCN

Aplicatiu desenvolupat amb tecnologia PHP, MySQL i SolR que dona servei web i publica una API RESTful de consulta d’actes per aplicatius clients. Ingesta de continguts a base de processos batch en la que es repliquen les taules de la base de dades ASIA, molt complert però amb una freqüència de actualització massa baixa, de l’ordre de 5 cops al dia. El gran problema és que tampoc resolt amb precisió el càlcul de les celebracions, ja que es basa en unes prediccions. En els casos d’actes amb horaris minimament complexes, el càlcul de celebracions és pràcticament nul, fins al punt que només processa dies amb dates exactes i els dies setmanals d’obertura a partir de la data d’inici. No obstant els seus temps de resposta són molt bons i no hi han problemes de càrrega gràcies als sistema de cache que utilitza. En un futur proper serà integrat amb el nou projecte ASIA i és la base dels serveis que en el projecte actual treballarem a partir d’unes modificacions que s’exposen en aquest document. En la part de la API l’objectiu és modificar els serveis existents pel correcte funcionament en la fase d’adaptació, i crear una nova API modificant la part de consulta a la base de dades. En la figura 4.4 es mostra un exemple de les cerques d’agenda que el ciutadà pot realitzar des de el portal de GuiaBCN, a fi d’entendre la imprecisió del càlcul de dates de celebració

13 Capítol 4. Introducció ja que en el “quan” tan sols indica un període de dies, la se va adreça és: http://guiabcn. bcn.cat.

Figura 4.4 - Web d’Agenda de l’Ajuntament de Barcelona.

4.3 Clients finals

Aplicacions de diferent caire que utilitzen les plataformes intermèdies descrites en el punt anterior o que directament ataquen ASIA via els serveis web. Dins de la solució cal preveure i estudiar quines eines i llibreries de programari existeixen al mercat per a que els clients puguin treballar amb el nou sistema, tant a nivell de format com de sincronització.

14 Capítol 4. Introducció

La investigació de llibreries a de ser sobre les tecnologies que utilitzen els client actuals que serien Drupal, Ruby, Python, Java, Wordpress, Joomla, Perl, etc. També cal tenir presents les eines de calendari, mòbils i d’altres de les que qualsevol usuari pugui disposar. Exemples d’aquest tipus podrien ser:

• Google Calendar • Microsoft Outlook • Mozilla Calendar (Mozilla Sunbird) • Lotus Notes • Mozilla Sunbird • Hotmail Calendar • Android • Iphone

4.4 Visites

Per conèixer per sobre la magnitud de peticions que rep ASIA a través de tota l’arquitectura a continuació llistem els mòduls més significatius i el nombre de visites mensuals.

Mòdul Visites mensuals

GuiaBCN 250.000 Templates ASIA 60.000 Serveis XML 3.000.000 Mobile Middleware 30.000

Total 3.350.000

Figura 4.5 - Taula amb nombre de peticions

Resumint, ASIA rep un total d’unes 3.350.000 peticions mensuals.

4.5 Arquitectura

Com s’ha vist en punts anteriors l’arquitectura de servei d’agenda i equipaments es redundant i complexe, per tant, és necessari reduïrla i eliminar els manteniments actuals.

15 Capítol 4. Introducció

En una fase final la ingesta d’actes haurà ser possible fer-la des de d’altres sistemes i/o clients i seguint un format estàndard. La finalitat és l’ha d’anar desactivant tots els mòduls intermedis a mesura que es vagin migrant els mòduls i aplicacions clients actuals a la nova solució. En la figura es mostra l’arquitectura final desitjada.

Figura 4.6 - Arquitectura final desitjada

4.6 Format de compartició

4.6.1 Serveis

En una primera instància s’hauran de modificar els web services per poder disposar de la nova funcionalitat als clients actuals, mantenint la compatibilitat, tot revisant l’afectació en cada un dels casos.

16 Capítol 4. Introducció

El gran objectiu però, serà la implementació d’una API REST per a consultes web amb diferents sortides (json, xml). Els clients finals han de poder accedir a tots el continguts d’ASIA. Aquests serveis disposaran d’una informació d’agenda més acurada que l’actual i incorporen sistemes per al càlcul d’events en el mateix client. El sistema de càlcul ha de partir d’un contingut de dades estàndard ofert pels serveis tant pels serveis nous com pels existents. L’objectiu és fer la transició de tal manera que els clients, i sobretot els nous clients, puguin aprofitar les noves funcionalitats de compartició dels horaris.

4.6.2 Calendaris

Caldrà poder crear i publicar dinàmicament actes per clients de correu, xarxes socials, mòbils, gestors de continguts i d’altres aplicacions. La idea es utilitzar el concepte de calendaris per permetre subscripcions a aquests tercers a l’estil webcal://www.example. com/Calendar.ics La finalitat dels calendaris es permetre la subscripció de clients utilitzen eines de caràcter general, sense la la necessitat de desenvolupaments. La creació de calendaris serà senzillament l’execució d’un servei parametritzable, amb tots els paràmetre d’una consulta de cerca via API, però exportable en format RFC5545. Aquest tipus de servei serà executat de manera interna, és a dir, controlant les actualitzacions amb la freqüència que un administrador determini. En un cas ideal es generarien en cada modificació del seus actes. La idea de calendari parteix de que pot ser compartit utilitzant un servidor WebDAV.

4.7 Sincronització

En la mida del possible la sincronització de modificacions ha de ser el més lleugera possible. S’han de proporcionar mètodes per al control de modificacions amb la màxima granularitat a nivell de contingut. Aquest control està orientat sobretot en el cas dels calendaris.

4.8 Resum dels problemes actuals

Per sintetitzar els problemes actuals de l’arquitectura, enumerem en les següents ratlles la problemàtica actual:

• Temps de resposta elevat.

17 Capítol 4. Introducció

• Desactualització de continguts. • Complexitat d’integració per part dels clients. • Manteniment de plataformes intermèdies. • Incompatibilitat amb clients actuals de propòsit general. • Ingesta de continguts propietària, i lligada a entorn web. No hi ha possibilitat d’importació de les agendes.

18 Capítol 5

Estudi de la solució i impacte

En aquest capítol es detallen les tasques de cada fase des de la implantació inicial fins a l’estat final.

5.1 Estudi d’alternatives

Per tal de donar solució al problema dels horaris s’ha realitzat un estudi del que oferia el mercat. Històricament les solucions de calendari eren totes propietàries i per tant fetes a mida. Les solucions implementades en llibreries de codi per cada tecnologia donaven un servei mínim a qui les utilitzava:

• poques funcionalitats • no disposaven de formats de compartició o eren massa senzills tipus arxius de text aplanats

Per tant, si es necessitava una gestió de calendari més complexe s’havia de construir a mida. Al 1998 apareix la primera especificació de calendari la rfc2445. Però no es fins molt més tard que comencen a implementar-se en clients de correu i en llibreries de codi en diferents tecnologies. A mesura que ha anat passant el temps la majoria de llibreries que ofereixen serveis d’horari han anant tirant cap a una implementació segons la rfc, fins al punt, que a dia d’avui, casi totes les solucions implementen una evolució de la primera que va sortir al 2009, la rfc5545. Actualment la majoria de clients de correu utilitzen aquesta especificació, encara que moltes de les vegades no implementen tota la casuística possible. Algunes d’elles per fer-nos una idea són:

19 Capítol 5. Estudi de la solució i impacte

• iCal de Apple • Mozilla Calendar (incloent Mozilla Sunbird) • Google Calendar • Lotus Notes • Hotmail Calendar • Microsoft Outlook

Per tant a l’hora de triar una solució ha estat ben senzill. S’ha escollit la rfc5545 com a base per a donar solució al projecte. En els estudis inicials que s’han fet, un estudi de casos detallat en l’annex i les necessitats de l’agenda de l’Ajuntament, s’ha vist que només amb la rfc5545 no donen solució complerta a les funcionalitats actuals. Per tant caldrà desenvolupar un sistema que, a grans trets, relacioni a un acte d’agenda amb múltiples events de la rfc5545. El detall aquest es detalla en els capítols 5 i 6, solució i desenvolupament respectivament.

5.2 Solució general

5.2.1 Ingesta

La ingesta ha de ser possible des de un entorn web d’administració basat en formularis i a partir de la importació de calendaris en format RFC5545. En el projecte treballem directament amb els fitxers ics que generem a partir d’eines específiques que ho permeten La entrada des de formulari fa referència exclusivament als paràmetres d’horari i que determinen les celebracions que un acte pot tenir en el temps. Per tant queden fora d’aquest formulari el lloc, telèfons, responsables, classificacions, i la resta de camps que defineixen un acte. La part de disseny queda fora del projecte ja que el marcarà els patrons que es determinin en el nou projecte ASIA. Una recomanació seria implementar-lo amb alguna llibreria javascript que faci el control de les casuístiques possibles en la part de recurrència de les celebracions. Un bon exemple com a punt de partida seria el que es mostra en la figura, utilitzat per Google Calendar, on en funció de les seleccions es modifica el contingut que es presenta al usuari i alhora valida la consistència. Aquest javascript hauria d’arribar a generar el fitxer ics segons els estàndards de iCalendar. No és necessari que informi de tots els camps d’acte però si tots els relatius al horari. En el mercat existeixen llibreries javascript que realitzen aquesta tasca.

20 Capítol 5. Estudi de la solució i impacte

Figura 5.1 - Exemple formulari web per a la introducció d’horari

5.2.2 Aplanament de dades

Cada acte d’ASIA ha de tenir aplanada cadascuna de les seves celebracions per tal de poder fer cerques ràpides. Aquest és el procés en el que es calcula i persisteix en funció de la data d’inici, periodicitat i tot un seguit de paràmetres detallats en l’annex, les celebracions d’un acte en un període determinat, al que anomenem finestra d’aplanament. Cal mencionar que aquest procés no sempre és necessari ja que una gran majoria dels actes no responen a criteris de repetició i es celebren una vegada. La finestra és necessària degut a que existeixen actes de l’agenda que no tenen una data de finalització en la seva repetició, o que a priori, no n’han de tenir. En tot cas es pot modificar o donar de baixa posteriorment.

Identificador Acte Dates de celebració

...... 1 02/03/2014 10:00 1 09/03/2014 10:00 1 16/03/2014 10:00 1 23/03/2014 10:00 1 30/03/2014 10:00 ......

21 Capítol 5. Estudi de la solució i impacte

2 05/03/2014 15:00 2 06/03/2014 15:00 ......

Figura 5.2 - Exemple de dates de celebració en taula d’aplanament

5.2.2.1 Finestra d’aplanament

Aquest aplanament es farà dins un període de temps determinat. La idea és de tenir una magnitud de temps fixe global per al sistema. La magnitud de temps vindrà serà determinada per l’administrador de l’eina i haurà de ser configurable. En l’actualitat una mesura semblant pel càlcul de dates estava definida per a 90 dies. No era un càlcul per part d’ASIA sinó de la programació de peticions per dia en la plataforma AsiaCache. Amb l’aplanament podem proposar una més gran ja que no implicarà cap tipus de càrrega al sistema i es podran oferir en horari actes preprogramats a molt temps vista. Coneixent els casos que es donen a ASIA proposem una finestra de 2 anys vista.

5.2.2.2 Control data modificacions

El procés es realitza per cada acte que es inserit o modificat, i deixant constància del moment, per tal de controlar quan s’han realitzat i així poder consultar i informar sobre les actualitzacions. Disposarem d’un servei que a partir d’una data informa de tots els actes modificats. Amb el control de dates quan el procés general d’aplanament es realitzi podem seleccionar quin actes calen ser aplanats i quins per el contrari al haver estat modificats recentment no necessiten ser aplanats. La condició proposem que sigui una data posterior a la realització de l’ultim aplanament. Així alliberem de càrrega al sistema en els càlculs. En cas que es cregui convenient forçar l’aplanament de absolutament tots els actes per mantenir una consistència, s’ha de poder obviar aquesta opció.

5.2.2.3 Manteniment funcionalitats actuals

L’aplanament ha de poder donar resposta als serveis actuals, com son, el càlcul de proper acte a partir d’una determinada data/hora, així com la generació de graelles, que dona resposta a totes les celebracions que un acte té durant un període determinat.

22 Capítol 5. Estudi de la solució i impacte

La idea és que la solució construïda permeti adaptar ASIA amb el menor cost possible. És per això que caldrà estudiar amb exactitud tot el referent al càlcul de celebracions d’actes d’ASIA. Inclou des de la persistència dels horaris com els serveis de cerca i sobretot, els procediment de càlcul de pròxima celebració.

5.2.3 Incorporació informació als serveis

Dins dels serveis haurem de serialitzar el contingut de l’horari d’un acte, per a que el consumidor client pugui processar i calcular les celebracions de manera autònoma sense tenir que d’adaptar-se als nous serveis en un primer moment. Podran existir actes amb l’horari nou i d’altres que no. Orientat a campanyes temporals on els actes que si celebren són nous i per tant en el nou format, i amb un petit subconjunt d’antics però que poden ser migrats al nou sense gran cost. A part la modificació dels antics als nous es pot realitzar per part dels responsables que mantenen i informen ASIA diàriament i preparen aquest continguts. Calculem que aquest afectarà directament als serveis XML d’ASIA i no tindran una vigència gaire llarga. Exclusivament en el procés de migració fins que tots els actes estiguin en el nou format i els client hagin canviat l’API de consulta a la nova API. Per als serveis GuiaBCN serà senzillament una petita ampliació dins els serveis que ja existeixen. En el XML l’horari serà un objecte calendari, seguint la RFC5545 i que contindrà els event necessaris que defineixen l’acte:

99400336556 Concert "Stash! R & R Club Live" ...

5.3 Requeriments d’un acte/event

En aquest punt determinem les propietats d’un event de l’Ajuntament de Barcelona. Parlarem d’event per que un acte podrà tenir associat més d’un event degut a les limitacions de l’especificació i la complexitat d’un acte, pel que hem deduït en un estudi inicial de la normativa RFC5545. Actualment la rfc5545 defineix el format de dades iCalendar per a la representació i l’intercanvi de calendaris i la programació d’informació com ara events, tasques pendents,

23 Capítol 5. Estudi de la solució i impacte entrades de dia, informació de lliure/ocupat, independentment del protocol o servei de calendari. El problema es que la definició d’event està limitat a una sèrie de paràmetres que no permet definir determinats events més inusuals. El format rfc5545 per a representació i compartició d’events està limitat vers els requeriments als que s’enfronta una agenda complexe com ara la de la ciutat de Barcelona. Revisant els possibles clients de l’agenda i compatibles amb la RFC5545 es constata que la majoria s’adapten perfectament:

• Eines gestió de calendari • Llibreries per a mòbils • Xarxes socials • Gestors de continguts, cal revisar les llibreries que tenen ja que sembla que no tenen implementacions completes segons la RFC5545 • Tecnologies de desenvolupament de programari de propòsit general

En l’annex detallem les necessitats actuals d’agenda i les possibilitats que ofereix la RFC5545.

5.3.1 RFC5545

El estàndard també es coneix com “iCal”, degut al nom del programa d’Apple, que va ser la primera aplicació en implementar-lo. L’abstrac del document de la normativa és “Aquest document defineix el format de dades iCalendar per representar i intercanviar el calendari i la informació de programació, tals com events, les tasques pendents, les entrades del diari i informació de disponibilitat, independenment de qualsevol servei de calendari o protocol.” La especificació iCalendar és el resultat del treball del Comité de Calendari i Agendes del IETF (dirigit per Anik Ganguly de Open Text Inc.), i va ser redactat per Frank Dawson de Lotus y Derik Stenerson de Microsoft. iCalendar es basa fortament en l’especificació anterior vCalendar, fruit del Consorci de Correu d’Internet (IMC). Ha estat implementat en una varietat de programes incloent el iCal de Apple, Mozilla Calendar (incloent Mozilla Sunbird), Google Calendar, Chandler, Lotus Notes, Sche- duleWorld, KOrganizer, Mulberry, Evolution de Novell, Kronolith, Simple Groupware, Hotmail Calendar, Nuvvo, Microsoft Outlook i Trac.

5.3.2 Horari d’un acte actual

En aquest punt mostrem les possibilitats d’horari que tenen els actes actuals d’ASIA. Per a una major comprensió s’afegeixen captures de l’eina d’ingesta dels continguts d’horaris.

24 Capítol 5. Estudi de la solució i impacte

ASIA permet 20 entrades per crear un horari d’acte. Cada entrada ve a ser una fila, en la que si un dels seus paràmetres no esta definit hereda el paràmetre de l’entrada/fila anterior. Els paràmetres de configuració que mostrem a continuació fan referència a una sola entrada. Es poden definir una o més entrades fins a 20. El resultat d’això es que per cada període poden variar els dies i les hores, i igualment, en funció dels dies i període també poden variar les hores. És completament configurable, i per tant complexe.

Figura 5.3 - Exemple d’horari amb diferents entrades.

En el horari d’exemple es veuen que per determinats períodes s’obren un dies o uns altres. Al igual passa amb les hores, qu per determinats períodes i dies les hores d’obertura o celebració són diferents.

5.3.2.1 Període

Permet definir sobre quin període de temps té validesa l’acte. Es defineix amb paràmetres de data d’inici i data de finalització, ambdós inclosos.

Figura 5.4 - Períodes d’obertura.

25 Capítol 5. Estudi de la solució i impacte

5.3.2.2 Dies

És la part més delicada del horari. Sobretot perquè la casuística possible en el que respecte a les dates relatives i que implica repeticions dels actes genera molta complexitat tant a la hora de calcular celebracions com a l’hora de presentar la informació al usuari. La generació de dies festius i vigílies de festius per cada any es configurable ja que apart de les festivitats fixes hi han les variables. Part important en aquest punt es posar ordre i aportar un punt de seny als administradors ja que alguns dels possibles casos que en el seu temps es van contemplar mai han estat definides.

5.3.2.3 Dies obertura regulars

Determina dies de la setmana d’obertura de dilluns a divendres i caps de setmana, i permet incloure o excloure festius i vigílies de festius. Festius i vigílies tenen prioritat davant dels regulars.

Figura 5.5 - Dies obertura regulars.

5.3.2.4 Dies exactes inclosos

Defineix una llista de dies en la que l’acte es celebra. Aquesta llista té preferència sobre les celebracions calculades a partir dels dies d’obertura regular, inclosos festius i vigílies de festius, i de les dates relatives.

Figura 5.6 - Dies exactes inclosos.

26 Capítol 5. Estudi de la solució i impacte

5.3.2.5 Dies exactes exclosos

Defineix una llista de dies en la que l’acte no es celebra. Aquesta llista té preferència sobre les celebracions calculades a partir dels dies d’obertura regular, inclosos festius i vigiles de festius i de les dates relatives.

Figura 5.7 - Dies exactes exclosos.

5.3.2.6 Dates relatives

Permet definir dates relatives en base al mes com ara el primer, segon, últim, penúltim, etc, de un determinat dia de la setmana i programar si està inclòs o exclòs. Te prioritat respecte els dies d’obertura regulars però no sobre les dates exactes incloses i excloses. Es poden definir tots els necessaris. Aquesta funcionalitat tot i que utilitzada, en els cas de l’agenda rarament ha estat usada i es podria haver resol amb les dates exactes. Aquesta funcionalitat estava pensada en un origen per horari d’equipaments.

Figura 5.8 - Dates relatives.

27 Capítol 5. Estudi de la solució i impacte

5.3.2.7 Hores

Definim l’hora d’inici i l’hora de fi de l’acte.

Figura 5.9 - Hores d’obertura i/o duració.

5.3.3 Exemples d’horari

A continuació mostrem en les diferents figures exemples d’horari. En el primer dels casos existeixen varies entrades com comentàvem en el punt 5.2.2, és a dir, tenim diverses entrades per dies ja que en funció d’aquests varien les hores de celebració. Això afecta directament al càlcul i per tant es vital distingir-los. Aquest tipus d’horari forma part de la minoria de casos però que cal resoldre.

Figura 5.10 - Exemple d’horari amb vàries entrades.

L’horari següent és el més simple i el més habitual on un acte es celebra un dia i auna hora

Figura 5.11 - Exemple d’horari amb entrada única.

28 Capítol 5. Estudi de la solució i impacte

29 Capítol 5. Estudi de la solució i impacte

5.4 Integració part client

Degut a les diferents plataformes que a dia d’avui estant consultant ASIA i a les que en un futur proper s’hi afegiran hem realitzat un petit estudi de quines eines hi ha al mercat per tal que els clients disposin d’una ajuda alhora d’integrar el nou serveis. El propòsit d’aquest petit estudi era identificar llibreries i mòduls que permetessin:

• Integrar calendaris complerts i processar-los. • Gestionar la presentació dels calendaris. • Control de modificacions i sincronització.

A continuació detallem la llista que hem confeccionat: Ruby

• http://icalendar.rubyforge.org/ • https://rubygems.org/gems/icalendar2

Java

• http://wiki.modularity.net.au/ical4j/index.php?title=Main_Page • https://github.com/bkiers/ICalParser

PHP

• http://kigkonsult.se/iCalcreator/

Drupal

• https://drupal.org/project/views_ical • https://drupal.org/project/date_ical • https://drupal.org/project/ical

Wordpress

• http://wordpress.org/plugins/tags/icalendar • https://wordpress.org/plugins/ical-for-wp-calendar/

Perl

30 Capítol 5. Estudi de la solució i impacte

• http://search.cpan.org/~rbow/Date-ICal-2.678/lib/Date/ICal.pm • http://search.cpan.org/~srl/Net-ICal-0.15/lib/Net/ICal.pm • http://search.cpan.org/~rfrankel/iCal-Parser-1.16/lib/iCal/Parser.pm

Python

• https://pypi.python.org/pypi/icalendar • https://pypi.python.org/pypi/django-ical

Joomla

• http://zcontent.net/products/zapcalendar • http://www.thejoomlacalendar.com/

Node.js

• https://www.npmjs.org/package/ical • https://github.com/tritech/node-icalendar

Javascript

• https://github.com/mozilla-comm/ical.js/ • https://github.com/kewisch/ical.js/ • http://keith-wood.name/icalendar.html • https://github.com/thybag/JavaScript-Ical-Parser

5.5 Implantació

5.5.1 Incorporació dins ASIA del nou mòdul

La instal·lació del nou mòdul dins ASIA permetrà tenir el actes perfectament agen- dats. Es podran crear calendaris i accedir als nous serveis. D’aquesta manera els nous clients/aplicacions podran desenvolupar seguint el nou mètode. Els CMS i els aplicacions mòbils podran usar-lo directament. Es crearan calendaris personalitzats per webs producte (Mercè, Grec, BCN Negre, . . . ) i per a portals amb agendes pròpies com ara Biblioteques, Educació, Cultura, Esports, Districtes, etc. Una part important es la integració de Guia BCN amb el nou format per tal que la seva API aprofiti les noves funcionaliats. Aquestes noves funcionalitats fa referència a la cerca d’actes per data i una per altre banda a la incorporació del horari. Aquesta API serà adaptada com a nova API dels serveis ASIA.

31 Capítol 5. Estudi de la solució i impacte

5.5.2 Adaptació serveis actuals

La modificació dels serveis actuals permetrà als clients disposar de la nova informació en cas que els interessi, basicament del horari serialitzat i completament informat. Una primera modificació serà el càlcul de celebració d’actes i que serà completament transparent en tota l’arquitectura ja que serà ASIA qui realitzarà aquesta tasca des de el seu core. Per tant, es manté la compatibilitat mantenint els serveis actuals però utilitzant el nou sistema per als actes que ja tinguin el nou horari i el antic pels actes pendent de migrar. Es mantenen les cerques per dia concret per als serveis web que nodreixen a Middleware, AsiaCache, i d’altres. En una fase posterior les aplicacions clients de Middleware, AsiaCache, etc, hauran de ser modificats per a consultar la nova API. En la figura veiem el funcionament de l’arquitectura en un moment d’adaptació de canvis i de nous desenvolupaments.

Figura 5.12 - Arquitectura intermèdia en el procés de migració i de funcionament dual

32 Capítol 5. Estudi de la solució i impacte

5.5.3 Revisió de l’arquitectura

A mida que es vagin migrant i adaptant els mòduls clients, s’anirà revisant l’ús de les parts de la arquitectura que deixin de ser necessàries. La revisió té com a finalitat eliminar les plataformes intermèdies i per tant el seu cost de manteniment i de màquina.

5.5.3.1 Actes migrats

Serà el moment en que tots els actes ASIA hagin estats migrats al nou sistema i per tant tots el actes tinguin el seu horari disponible en els nous serveis. Tots els nous clients a partir d’aquest moment només podran atacar ASIA via la nova API. Quedarà pendent l’adaptació dels actuals, però tots ells disposaran d’un servei de càlcul de dates de celebració precís.

5.5.3.2 Clients migrats

Punt en el que les aplicacions antigues ja utilitzen els nous serveis. Anirem controlant l’ús de les plataformes intermèdies amb la fi d’eliminar-les. En el cas d’AsiaCache caldrà identificar les peticions que deixen de tenir utilitat i les anirem eliminant gradualment.

5.5.4 Fi d’implantació

En una fase final, no hi haurà cap aplicatiu client que utilitzi els serveis antics i passarem a eliminar els mòduls intermedis. Podem veure l’esquema final en la figura 4.6

5.6 Sincronització

5.6.1 Serveis

Per tal de fer la ingesta de continguts en els clients, els nous serveis de llistats i detalls, informaran de la data d’última actualització i així evitar processos repetitius de modificació de bases de dades en els sistemes externs.

33 Capítol 5. Estudi de la solució i impacte

5.6.2 Calendaris

La sincronització amb el control de canvis es podrà fer en base a propietats que hem definit en l’estructura d’event. Concretament la propietat de última modificació (last-mod). La majoria de clients iCal de propòsit general ja utilitzen aquest paràmetre per gestionar internament les modificacions.

34 Capítol 6

Desenvolupament

6.1 Ingesta

La part d’introducció de continguts lligats a les agendes la descrivim en els següents apartats.

6.1.1 Importació calendaris

És la via que permet importar agendes de fonts externes de manera massiva. El procés parteix d’un únic arxiu que segueix la especificació RFC5545. La importació conta amb una part de verificació per part dels administradors d’ASIA. Des de el moment que un acte és gestionat d’aquesta manera passa a estar disponible pels nous serveis de consulta.

6.1.2 Formularis web

Dins l’administració ASIA existeix un formulari que permet definir les propietats horàries d’un acte. Entenem com a propietats les definides en l’especificació RFC5545, com ara:

• data/hora inici • data/hora fi • periodicitat • data fi de la periodicitat • nombre de repeticions • dates excloses

35 Capítol 6. Desenvolupament

Cal dir que la part més complexe ha estat la de definir la periodicitat, ja que les possibilitats segons l’especificació són molt amplies. Des de el moment que un acte és gestionat d’aquesta manera passa a estar disponible pels nous serveis de consulta. A continuació es mostra un exemple de calendari en format RFC5545:

BEGIN:VCALENDAR VERSION:2.0 PRODID:ajbcn.calendari_9933248632 METHOD:PUBLISH BEGIN:VEVENT UID:[email protected] DTSTAMP:20140512T112510Z TITLE:Jornada de Portes Obertes DTSTART:20140126T103000Z DTEND:20140126T114500Z DESCRIPTION: Descripció de l'acte LOCATION:lloc on es celebra acte RRULE:FREQ=MONTHLY;UNTIL=20241230T230000Z END:VEVENT END:VCALENDAR

6.2 Persistència d’actes

És la part en la que s’emmagatzema un acte per al nou sistema i que servirà als nous serveis i al sistema antic per al control d’actes nous. Entre els punts a destacar cal mencionar que aquí és on es relaciona l’acte ASIA amb:

• el seu calendari per tal de ser compartit de manera estàndard, • la data i hora de la seva última modificació per tal d’actualitzar calendaris globals pregenerats i serveis d’informació d’actualitzacions. • la data i hora de la última vegada que es van aplanar les seves celebracions, útil per al procés de aplanament general.

La informació que caldrà emmagatzemar a la taula EVENT serà:

• identificador acte • identificador event • ics, calendari de l’event serialitzat

36 Capítol 6. Desenvolupament

• data/hora última modificació • data/hora aplanament

El camp ics o calendari del event, és la base de tot el sistema d’horaris. Aquest camp conté el calendari de l’acte seguint la especificació RFC5545. Conté tots els paràmetres necessaris per a determinar la celebració de l’acte i per tant el punt d’entrada per a les rutines d’aplanament. En la creació del ics utilitzarem la funció següent i assignarem un identificador únic al calendari amb diferents paràmetres com ara el identificador de l’acte mitjançant un objecte de configuració:

$config = array( "unique_id" => "guia.bcn.cat_99402235002" , "TZID" => $tz );

En la funció anterior afegiem també la zona horària, a continuació creem el calendari:

$vCalendar = new vcalendar( $config ); i després associarem la resta de camps ASIA al calendari de l’acte per tal de generar el ics definitiu. No inclourem cap paràmetre de horari propiament ja que aquest ens ve donat de l’event original i que ens arriba de la part d’ingesta.

$vevent->setProperty( "LOCATION", $lloc ); $vevent->setProperty( "DESCRIPTION", $comments ); $vevent->setProperty( "ORGANIZER", $responasble_organitzacio ); ... posteriorment assignarem l’horari de l’acte l’estructura del calendari.

$vCalendar->getComponent( "vevent" )

Finalment guardarem l’acte per a que estigui disponible per al sistema nou. En aquest cas $event fa referència a una acte ASIA, el qual pot tenir diferent events RFC5545 associats. function saveEvent ($event)

1. Insereix o modifica la entrada en la taula EVENT per acte 2. Realitza aplanament i guarda data d’aquest aplanament 3. Guarda la data de modificació

L’identificador d’event es per assignar una altre configuració d’horari al mateix acte ja que de vegade un sol event RFC5545 no és suficient per definir un horari ASIA. A continuació mostrem el model entitat relació de la base de dades.

37 Capítol 6. Desenvolupament

6.2.1 Model BBDD

En la figura següent es mostra el diagrama entitat relació.

Figura 6.1 - Model ER de la solució.

6.2.2 Camps d’un acte dins RFC5545

Per tal de poder informar els actes en el format RFC5545, hem inserit dins la estructura que segueix estrictament la normativa, els camps dels actes, i dels quals la normativa contempla la seva existència. A continuació es descriu el mapeig realitzat entre camps d’acte ASIA i el calendari RFC5545:

• class: PUBLIC • description: comments • geo: coordaddressx i coordaddressy • lloc: en un futur es podria especificar una url CID [RFC2426] on trobem una vCard. De moment serialització de diferents camps per conformar una adreça: – street – streetnum_i – district – barri – postal_code – city

• organizer: relation, en funció del tipus de relació • status: TENTATIVE o CONFIRMED • url: url al detall de l’acte al site de guia.bcn.cat • categories: classification

38 Capítol 6. Desenvolupament

• contact: phones i interest_info • related: relation, en funció del tipus de relació • resources: relation

La persistència d’aquests camps és realitza en les funcions detallades en el punt 6.2 Aquesta punt només te sentit en la generació de calendaris ja que els serveis que ofereix la API tenen molt més contingut i no es poden emmagatzemar en un fitxer ics.

6.3 Aplanament de dades

L’aplanament permet, definint una finestra temporal, determinar totes les celebracions que un acte tindrà i persistenciar-les en una taula a fi de ser consultades el més ràpid possible. Aquesta taula serà consultada per la nova API que donarà servei al clients i pel sistema antic en el procés intermedi fins que no quedi cap acte en el format antic. La informació que caldrà emmagatzemar serà:

• identificador acte • identificador event • data/hora d’inici del event • data/hora finalització del event

El aplanament es durà a terme: - cada vegada que un acte nou sigui introduït o modificada la seva part de horari. - cada cert temps hi haurà un procés que torni a aplanar tots els actes segons finestra. L’aplanament és la part més delicada del projecte ja que requereix d’un algorisme que en funció de tots els paràmetres d’entrada que defineixen el horari determina les dates de celebració per a cada acte. La casuística possible així com els possibles casos es mostren en l’annex que lliurem junt amb aquest document. function aplanament($vEvent, $enddate = false)

1. Elimina tots els registres associats al identificador de l’acte. 2. Execució de l’algorisme de càlcul de dates de celebració. 3. Persistència de les dates de celebració juntament amb la seva durada.

vEvent: és l’objecte que conté tota la informació o calendari de l’acte proposat per la RFC5545. enddate: és la data de finalització de càlculs de celebracions.

39 Capítol 6. Desenvolupament

La funció utilitza una llibreria que calcula les celebracions en el cas d’un horari amb repeticions: iCalUtilityFunctions::_recur2date( $result, $rrule, $wdate, $startdate, $enddate );

on

• $result: és l’array resultant amb els dies i hora de la celebració • $rrule: és el patró de freqüència • $wdate: component de la data d’inici • $startdate: data d’inici • $enddate: data de fi

En el cas que no hi hagi component recursiu la mateixa funció d’aplanament s’encarregarà de fixar la data en la taula CALENDARI. Per a la tasca d’aplanament hem utilitzat la llibreria iCalCreator-2.18 iCalcreator és un paquet de classes PHP per a la gestió d’arxius iCal, el suport a sistemes de calendari i les aplicacions per a processar i comunicar informació de l’agenda, com esdeveniments, agendes, tasques, informes, todos i informació de diari. La especificació que segueix iCal són estrictament la RFC5545/RFC5546. Les tasques que realitza iCalcreator són les de crear, analitzar, editar i seleccionar calendaris i components de calendari, en el nostre cas events. El paquet iCalcreator , construïda d’una classe de calendari amb el suport d’unes funcions de la classe i la funció d’ajuda , són propietat de component calendari orientat . Per iCalcreator 2.18 versió ( i més tard ) , la versió de PHP > = 5.2.0 es requereix , a causa de la utilització de la classe DateTime de PHP ( i funcions associades ) .

6.4 Creació serveis

Aquests nous serveis estar orientats a productes que els seus resultats formin part d’agendes noves i que per tant quedin excloses agendes antigues que encara no hagin estat migrades al nou format. Mentre la resta d’actes no hagin estat migrats, les noves webs producte de l’Ajuntament ja podran oferir les funcionalitats de calendari com ara la compartició a clients que puguin processar RFC5545 i la millora de les cerques per data, i reduir el cost de càlcul, punt crític en webs d’aquest caire. Webs d’aquest tipus tenen les característiques que estan a viu un petit període de temps i que el seu nombre de visites és molt elevat.

40 Capítol 6. Desenvolupament

També és vital el control de modificacions d’actes per tal de tornar a sol·licitar exclusiva- ment la informació que ha estat actualitzada. Exemple d’aquest tipus de webs són:

• Mercè • BCN Negra • Sant Joan • Grec • Nadal • Campanyes d’escoles • Inscripcions escoles bressol • ...

6.4.1 Definició del Serveis web RESTful (API)

REST (Representational State Transfer) és una arquitectura de programari pensada per sistemes distribuïts basats en hipermèdia, com ara el web. Aquest terme va ser introduït l’any 2000 en una tesi doctoral sobre arquitectures de programari de xarxes. Aquesta tesi va ser escrita per Roy Thomas Fielding i dirigida per Richard N. Taylor. Roy va ser un dels principals autors de les especificacions del protocol HTTP i explica en la seva tesi com es pot aprofitar aquest protocol per tal de desenvolupar aplicacions distribuïdes. Tot i que en un principi REST es referia tan sols a un conjunt de principis d’arquitectura de xarxa i la definició i adreçament dels recursos, actualment aquest concepte s’utilitza per referir-se a una interfície web que utilitza XML/JSON i HTTP sense cap conjunt de capçaleres com podria ser en el cas de SOAP i XML-RPC. Segons la tesi de Roy es poden dissenyar interfícies XML/JSON+HTTP seguint la filosofia de Remote Procedure Call sense utilitzar la complexitat del protocol SOAP. Un servei web REST (també anomenat REST Web API ) és un servei web implementats utilitzant HTTP i els principis de REST. Es tracta d’una col·lecció de recursos, amb quatre aspectes definits:

1. La URI base per al servei web, com http://example.com/resources/ 2. el tipus de mitjans d’Internet de les dades compatibles amb el servei web. Això sovint és JSON , XML o YAML , però pot ser qualsevol altre tipus de mitjà d’Internet vàlida. 3. el conjunt de les operacions recolzades pel servei web utilitzant mètodes HTTP (per exemple, GET, PUT, POST o DELETE). 4. Els mètodes públics són executats pels quatre mètodes HTTP disponibles per REST- ful: GET, POST, DELETE, PUT

41 Capítol 6. Desenvolupament

Els mètodes GET i POST són coneguts en els formularis ( ). Cadascun d’aquests mètodes determina l’acció que farà el REST sobre la nostra aplicació. No han d’haver més d’un GET o POST o DELETE o PUT, només ha d’haver un de cada mètode. Cada un té una tasca especifica:

• GET: Per obtenir un valor. Pot ser una llista d’objectes • POST: Per desar un nou objecte (instància de identitat) en l’aplicació • DELETE: Per eliminar un objecte (instància d’identitat) • PUT: Per actualitzar un objecte.

6.4.1.1 Mètodes GET implementats

El paràmetres xout i ajax combinats amb qualsevol altre paràmetre, permeten accedir a els serveis XML/JSON de la GUIA. Ajax = bloc (normalment el mateix que pg) xout = 1 , retorna XML xout = json , retorna JSON (si es 1 retornarà XML, si no posem xout retornarà el HTML corresponent, que es el que utilitza l’ajax) Hi ha una descripció completa del paràmetres disponibles en el següent punt. Exemple : Les següents URLs retornen l’XML(es igual per JSON).

• Detall Agenda o equipament http://guia.bcn.cat/?pg=detall&id_doc=96318091405&xout=1&ajax=detall Inclou relacionats i vistos per altres usuaris.

• Agenda recomanada com a la GUIABCN (paginació de 5 resultats segons ) http://guia.bcn.cat/?pg=hrecom&from=0&xout=1&ajax=hrecom Aquest xml afegeix el jscript de gmaps (no seria necessari)

• Agenda recomanada com a HOMEBCN (una pagina amb nombre de resultats a ) http://guia.bcn.cat/?pg=homebcn&rows=5&xout=1&ajax=homebcn

• Mes vistos i mes valorats (5 resultats) http://guia.bcn.cat/?pg=mviewed&xout=1&ajax=mviewed

42 Capítol 6. Desenvolupament

• Mes valorats (5 resultats) http://guia.bcn.cat/?pg=mvoted&xout=1&ajax=mvoted

• Cerca (Veure paràmetres disponibles en el punt següent) http://guia.bcn.cat/?pg=search&q=&xout=1&ajax=search Aquest xml afegeix el jscript de gmaps (no seria necessari)

6.4.1.2 Estructura URLs

Hi ha dos tipus d’URLs:

• URL per paràmetres estàndard: ?param1=valor¶m2=valor • URLs SEO : Es corresponent amb un conjunt de URLs per paràmetres amb format SEO. No disponible per serveis XML/JSON.

Els serveis XML/JSON se obtenen combinant els paràmetres xout i ajax, amb qualsevol altre paràmetre. Veure estructura de paràmetres. Existeix la possibilitat de utilitzar caràcters “LIKE”: ? = accepta qualsevol caràcter. Ex : 001200?012150000 Acceptaria qualsevol caràcter en la posició * = Accepta un conjunt de caràcters. Ex : 001200?012150000* Acceptaria qualsevol acabament.

6.4.1.3 Mètodes GET per paràmetres

Aquestes tenen el format http://guia.bcn.cat/?param1=valor¶m2=valor.... Per consultar exemples de paràmetres fer servir http://guia.bcn.cat amb un firefox o Chrome(IE no actualitza les URLs amb AJAX)

Paràmetre Descripció pg Bloc php a executar (home,search,detall,homebcn,mviewed,hrecom) nr numero de resultats de la cerca per pg=search q Paraules a cercar per pg=search sort Cerca ordenada per popularitat o alfabeticament per pg=search code0 Cerca per Classificació primer nivel arbres agenda o equipaments per pg=search

43 Capítol 6. Desenvolupament districtstr Cerca per Districte per per pg=search from Posició inicial a retorna de Cerca (no es la Pagina), veure nr , per pg=search code1 Cerca per Classificació segon nivel arbres agenda o equipaments per pg=search d Cerca actes de la agenda per avui, dema, cap de setmana, caps.. per pg=search p Cerca actes de la agenda per preu per pg=search. Veure filtre Web guia ticket Cerca actes de la agenda per tipus de tiquet per pg=search. Veure filtre Web guia type Cerca per tipus Agenda AG o equipament EQ per pg=search (AG o EQ) id_doc Entity_id per pg=detall code2 Cerca per Classificació tercer nivel arbres agenda o equipaments per pg=search code3 Cerca per Classificació quart nivel arbres agenda o equipaments per pg=search idma Idioma de visualització (ca o es o en) lk Votació m’agrada per a una agena amb pg=detall (y) code4 Cerca per Classificació cinque nivel arbres agenda o equipaments per pg=search code_info Informació adicional. code_tit Titularitat privada/public code5 Cerca per Classificació sisè nivel arbres agenda o equipaments per pg=search c Codi de tematica for a del arbre de internet. Inclou tots els altres arbres. Separats per comes es fa un OR I si es separa per ; es fa un AND Cf Filtres per codi tematic internet separats per comes. Serveix per ajuntar codis. barristr Cerca per Barri per pg=search t Cerca per paraula amb pg=search 1=Totes les paraules, 2 Qualsevol paraula, 3 Frase exacte ad Cerca per carrer amb pg=search ini Cerca per numero inici del carrer amb pg=search, ad=carrer fi Cerca per numero fi del carrer amb pg=search, ad=carrer dt Cerca per interval data amb pg=search, es pot posa una data o dues diferents xout Retorna la petició GET en format XML/JSON canal Segmentació de les dades per una web. Ex: escoles, ccivics ajax Retorna només la sortida del bloc executat eliminant el header, footer, etc. . . de tota la pàgina

44 Capítol 6. Desenvolupament

6.4.1.4 URL SEO

Les URL SEO estan disponibles per a el detall. Te el següent format: http://guia.bcn.cat/titol-del –document-agenda-o-equipament_.html>

Es format següent son dos variants diferents per forçar el idioma de visualització. http://guia.bcn.cat/titol-del –document-agenda-o-equipament__.html> http://guia.bcn.cat/titol-del –document-agenda-o-equipament_.html?idma=>

Qualsevol URL amb text, guio baix punt html, s’interpreta com la URL següent : http://guia.bcn.cat/?pg=detall&id_doc=

Exemple : http://guia.bcn.cat/horari-ilmiddotluminacio-font-magica-fonts-de-montjuic-_ 96318091405.html http://guia.bcn.cat/horari-ilmiddotluminacio-font-magica-fonts-de-montjuic-_ 96318091405_ca.html http://guia.bcn.cat/horari-ilmiddotluminacio-font-magica-fonts-de-montjuic-_ 96318091405.html?idma=ca es igual que : http://guia.bcn.cat/?pg=detall&id_doc=96318091405

6.5 Resum nous serveis

6.5.1 Llistats d’actes

Servei de cerca d’actes en funció de diversos paràmetres que retorna un llistat. Amb el calendari serialitzat o una referència a ell.

6.5.2 Detall d’actes

Servei que retorna un acte amb tota la seva informació. Té dos tipus de sortida:

• Format calendari RFC5545. • Format XML que inclou el calendari serialitzat.

Amb el calendari serialitzat o una referència.

45 Capítol 6. Desenvolupament

6.5.3 Creació de calendaris

Servei de cerca d’actes en funció de diversos paràmetres que retorna un únic arxiu en format RFC5545. És un calendari complert d’actes, idealment, per a webs producte amb un conjunt d’actes clarament agrupats. La informació iCalendar es declarada com un tipus de contingut MIME text/calendar. S’ha d’utilitzar l’extensió “ics” per anomenar al fitxer que tingui (una quantitat qualsevol de) informació de calendari i agenda consistent amb aquest tipus MIME. Els arxius iCalendar son arxius de text plà ASCII, en els quals cada lines de text acaba amb CRLF (caràcter hexadecimal 0D0A).

6.5.3.1 Funció function crearCalendari($llistatEvents)

1. Es recupera el calendari de cada acte del llistat d’events, previ cerca, de la taula EVENTS. 2. S’elabora un document resposta en format RFC5545. Un calendari únic que inclou tots els actes de la llista

6.5.3.2 Nou servei calendari

Es crea un nou servei, idèntic a l’actual en els paràmetres de cerca i es modifica la sortida ja que consultant la taula EVENTS es retornen tots els calendaris RFC5545 dels resultats. Posteriorment es genera el document resposta. Per aquesta tasca generem un identificador únic de calendari i agreguem les estructures ics dels actes resultants, en la iteració anirem afegint els events amb la funció:

$vCalendarResult->setComponent( $vevent, $uid )

on

• $vCalendarResult: és el calendari resultat de la cerca • $vevent: cada un dels actes resultants • $uid: l’identificador de l’acte i de l’event dins el calendari

46 Capítol 6. Desenvolupament

6.6 Adaptació sistemes actuals

Per evitar una migració inicial dels actes al nou format, es modificaran les consultes antigues per a que realitzin les cerques en el sistema antic i el nou i pugui diferenciar quins actes estant en un sistema o en l’altre. A tal efecte hem creat una nova taula ACTES_MIGRATS on els actes estaran marcats com a nou o antic, i on inicialment estaran tots marcats com antics, és a dir, no migrats. Bàsicament hem modificat la consulta a BBDD actual per a que en les cerques que fan el càlcul de data de proper actes les antigues segueixin el mètode de les funcions plsql que permeten calcula la data de propera celebració i les noves vagin a la taula de l’aplanament.

6.6.1 Serveis web ASIA

6.6.1.1 Llistat d’agenda

Modificació de la cerca a nivell de base de dades per tal d’obtenir les dates de pròxima celebració dels actes antics i dels actes nous. Es modifica la funció plsql de tal manera que pels actes antics el funcionament sigui igual i pels nous es consulti la nova taula CALENDARI on estan les celebracions aplanades. La discriminació antics vers els nous esta reflexada en la taula ACTES_MIGRATS. Un dels objectius del projecte era que el sistema actual no necessites de canvis costosos i el codi següent és una modificació de quatre ratlles en el codi. Resulta que el càlcul de les dates de celebració la realitza una única funció plsql i per tant no cal modificar cap de les queries SQL ni cap part de codi java per a l’adaptació al nou sistema. A continuació es mostra el codi modificat de la funció plsql:

CREATE OR REPLACE FUNCTION ASIA_U.ORFPROXDATE2 ( p_entity_id IN NUMBER, p_datacerca IN DATE, a_lang IN NUMBER ) RETURN VARCHAR2 IS dataPropera DATE; dataObertura DATE; dataCercaReal DATE; -- Duplicarem els CLOSEDDAYS per realitzar el calcul més fàcilment tancats VARCHAR2(14); temp NUMBER; diesPerObrir NUMBER;

47 Capítol 6. Desenvolupament

tmpData date; tmpData2 date; nQuadrar number; aproxDate VARCHAR2(500); relatDate VARCHAR2(500); tipusActe VARCHAR2(1); migrat VARCHAR2(1); BEGIN tmpData2:=to_date(to_char(p_datacerca,'DD/MM/YYYY hh24:mi'),'DD/MM/YYYY hh24:mi');

-- Inici Codi Projecte -- Si es acte sistema nou select A.MIGRAT into migrat from ACTES_MIGRATS A where A.ID_ASIA = p_entity_id; if (migrat = '1') then SELECT min(data_inici) INTO dataPropera FROM CALENDARI WHERE ID_ASIA = p_entity_id AND data_inici >= tmpData2; if (dataPropera IS NOT NULL) then return to_char(dataPropera,'DD/MM/YYYY hh24:mi'); else return '31/12/9999'; end if; end if; -- Fi Codi Projecte

nQuadrar := 0; if (TO_NUMBER(TO_CHAR(to_date('3/2/2003','DD/MM/YYYY'),'D'))=2) then nquadrar := 1; end if; -- Si es de tipus Permanent retornem 31/12/9999 select A.ACTTYPE into tipusActe from AGENDA A where A.ENTITY_ID = p_entity_id AND A.LANGUAGE_ID = a_lang; if (tipusActe = 'E') then return '31/12/9999'; end if;

48 Capítol 6. Desenvolupament

-- Buscar en EXACTDATES i retornar SELECT min(EXACTDATE) INTO dataPropera FROM EXACTDATES ED, AGENDA A WHERE ED.ENTITY_ID = p_entity_id AND A.ENTITY_ID = p_entity_id AND ED.EXACTDATE >= tmpData2 AND A.LANGUAGE_ID = a_lang; if (dataPropera IS NOT NULL) then return to_char(dataPropera,'DD/MM/YYYY hh24:mi'); else null; end if; -- Busquem en CLOSEDDAYS els dies que obren select A.CLOSEDDAYS || A.CLOSEDDAYS into tancats from AGENDA A where A.ENTITY_ID = p_entity_id AND A.LANGUAGE_ID = a_lang; select A.BEGINDATE into dataObertura from AGENDA A where A.ENTITY_ID = p_entity_id AND A.LANGUAGE_ID = a_lang; -- AND p_datacerca BETWEEN A.BEGINDATE AND TO_DATE('31/12/9999','DD/MM/YYYY'); if (tancats is null) then return '01/01/9999'; end if; dataCercaReal := tmpData2; if (dataObertura is not null) then if (tmpData2

temp := TO_NUMBER(TO_CHAR (dataCercaReal, 'D') ) - nQuadrar; if (temp = 0) then temp := 7; end if; diesPerObrir := 0; LOOP

49 Capítol 6. Desenvolupament

if (SUBSTR(tancats, temp, 1) = '0') then tmpData := dataCercaReal + diesPerObrir; return to_char(tmpData,'DD/MM/YYYY hh24:mi'); end if; diesPerObrir := diesPerObrir + 1; temp := temp + 1; EXIT WHEN (temp >= 14); END LOOP;

-- Si te datas aproximades o relatives retornem 31/12/9999 select A.APROXDATE into aproxDate from AGENDA A where A.ENTITY_ID = p_entity_id AND A.LANGUAGE_ID=1; select A.RELATIVEDATES into relatDate from AGENDA A where A.ENTITY_ID = p_entity_id AND A.LANGUAGE_ID = a_lang; if ((aproxDate IS NOT NULL)or(relatDate is not null)) then return '31/12/9999'; end if; RETURN '31/12/9999'; END;

Opcionalment en el llistat de resposta i en funció de la crida es retornarà el calendari de l’acte nou serialitzat o bé una referència a ell, com mostra l’exemple:

:::xml

1 1 1 99400335131

50 Capítol 6. Desenvolupament

Concert "Jamie Cullum" Concert "Jamie Cullum" 92086008895 Poble Espanyol de Montjuïc # Av Francesc Ferrer Guàrdia 13 Sants-Montjuïc 08038 BARCELONA # 935086300 FAX 935086333 03/07/2014 21.00 P C V Música Jazz i blues

51 Capítol 6. Desenvolupament

VERSION:1.0 BEGIN:VEVENT DTSTART:20140307T220000 DTEND:20140307T233000 SUMMARY:Concert "Jamie Cullum" LOCATION:Poble Espanyol de Montjuïc DESCRIPTION: PRIORITY:3 END:VEVENT END:VCALENDAR]]>

Per a servir el calendari cal modificar el servei, detallem a continuació els canvis:

• package asi.helpers.controller.modules QueryNewLlistaAG.java protected void getData( boolean flag, List l ) throws Exception

• package asi.helpers.controller.modules QueryNewLlistaAG2.java private void getData() throws Exception

• package es.bcn.asi.entity Entity.java public Vector getAgendaByAdvancedSearchProperaMobil( Vector vGeneral, String sWords, Vector vClassifications, Vector vAddress, Vector vVariables, Vector vOthers, Vector vLlocs ) throws java.rmi.RemoteException, javax.naming.NamingException, java.sql.SQLException, javax.ejb.CreateException

6.6.1.2 Detall d’agenda

Utilitza la mateixa funció plsql que el llistat. En la resposta s’afegeix la possibilitat d’incloure el calendari. Per a servir el calendari el servei, detallem a continuació els canvis:

• package asi.helpers.controller.modules QueryModule.java: public void getDetallAgenda( Request req, Response res, String srutaRel, String srutaRelImatge ) throws Exception

52 Capítol 6. Desenvolupament

• package es.bcn.asi.entity Entity.java public Vector getAgendaByIdAndProperaDataXML ( Vector vKey ) throws ja- va.rmi.RemoteException, javax.naming.NamingException, java.sql.SQLException, javax.ejb.CreateException

6.6.2 Serveis GuiaBCN

Adaptació dels actuals serveis de la plataforma de GuiaBCN ja que molt probablement acabaran esdevenint els únics serveis de compartició d’agenda dins un futur projecte d’agenda i equipaments.

6.6.2.1 Llistat d’agenda

Al igual que en els serveis ASIA es modifica la cerca per calcular la data de propera celebració i s’afegeix la possibilitat d’incloure el calendari. Els formats de sortida seran en xml i json, per tal de mantenir la compatibilitat actual.

6.6.2.2 Detall d’agenda

Modificació del servei pel càlcul dual de data i la possible inclusió del calendari. Mateixos formats de sortida que en el llistat, xml i json.

6.7 Altres

6.7.1 Control de modificacions

Creiem que oferir un servei d’aquesta mena als clients, si es fa un bon ús, estalviarà un munt de peticions i consultes al sistema. Això comportarà que podrà augmentar la freqüència d’actualitzacions. Les noves entrades estaran apareixent amb la data de inserció i serà el client que s’ocuparà de recuperar-lo, els esborrats ja no apareixeran i s’actuarà d’igual manera. A banda en el cas de calendaris en els que continguin n events, les parts client i de fet, amb les llibreries adequades un cop obtinguin el calendari només seran processats per a la actualització aquells que la seva data de modificació hagi variat, i per tant descarregant a l’eina client de tasques massives de modificació. function actesModificats($data)

53 Capítol 6. Desenvolupament

1. Retorna una llista amb els identificadors dels actes modificats a partir de la data de cerca.

Consulta el camp DATA_MODIFICACIO de la taula EVENT.

54 Capítol 7

Anàlisi dels resultats obtinguts

7.1 Millora tècnica

La estatificació de continguts amb freqüències programables dona una eficiència molt gran en el consum de recurs dinàmics. Del conjunt de peticions anteriors web de l’ordre dels 3 milions mensuals es redueix a centenes diàries. La actualització d’un acte comporta un temps superior a l’actual:

• Modificació del horari serialitzat per incloure les modificacions i la data d’actualització. • En el cas de modificació d’horari en necessari l’execució del procés d’aplanament de dates.

7.2 Reducció costos

Desapareixen les plataformes intermèdies en un futur i per tant el seu manteniment. Queda relativament senzilla la integració de les agendes en els client i amb la llibertat d’utilitzar la tecnologia que prefereixin gràcies al conjunt de llibreries lliure disponibles.

55 Capítol 8

Conclusions

Una de les grans millores és l’objectiu principal del projecte, ara, podem compartir l’agenda d’una manera estàndard a qualsevol tipus de client. D’aquesta manera la integració és molt més senzilla i menys costosa. Els temps de cerca dels serveis més crítics són molt inferiors als antics. I gràcies a l’especificació RFC5545 ajustem i acotem les funcionalitats dels horaris dels actes. La informació d’agenda ja no està desactualitzada i només depèn dels clients la freqüència de refresc. A més a més disposaran de serveis de consulta de les modificacions. Es podran eliminar les plataformes intermèdies i per tant eliminar els costos de manteniment i que a més a més estaven repartits en diferents proveïdors.

56 Capítol 9

Línies de futur

• Tractament dels equipaments seguint les especificació vCard • Tractament de responsables, contactes seguint especificació vCard • Creació de calendaris a mida • Generació i compartició de dades Opendata • Creació de widget per la introducció dels horaris

57 Capítol 10

Índex de figures

• Figura 4.1 - Serveis web d’ASIA actuals • Figura 4.2 - Arquitectura actual Agenda i Equipaments de Barcelona • Figura 4.3 - Exemple Administració AsiaCache • Figura 4.4 - Web d’Agenda de l’Ajuntament de Barcelona. • Figura 4.5 - Taula amb nombre de peticions • Figura 4.6 - Arquitectura final desitjada • Figura 5.1 - Exemple formulari web per a la introducció d’horari • Figura 5.2 - Exemple de dates de celebració en taula d’aplanament • Figura 5.3 - Exemple d’horari amb diferents entrades • Figura 5.4 - Períodes d’obertura • Figura 5.5 - Dies obertura regulars • Figura 5.6 - Dies exactes inclosos • Figura 5.7 - Dies exactes exclosos • Figura 5.8 - Dates relatives • Figura 5.9 - Hores d’obertura i/o duració • Figura 5.10 - Exemple d’horari amb vàries entrades • Figura 5.11 - Exemple d’horari amb entrada única • Figura 5.12 - Arquitectura intermèdia en el procés de migració i de funcionament dual • Figura 6.1 - Model ER de la solució

58 Capítol 11

Bibliografia

Especificacions [1] Bernard Desruisseaux, “Internet Calendaring and Scheduling Core Object Specification (iCalendar)”, URL: http://tools.ietf.org/html/rfc5545. Últim accés: 2014]. [2] Wikipedia, “iCalendar - Wikipedia, the free encyclopedia”, URL: http://en.wikipedia. org/wiki/ICalendar. Últim accés: 2014]. [3] Kjell-Inge Gustafsson - kigkonsult, “kigkonsult PHP software”, URL: http: //kigkonsult.se/. Últim accés: 2014]. PHP [4] Kjell-Inge Gustafsson, “kigkonsult iCalcreator”, URL: http://kigkonsult.se/ iCalcreator/. Últim accés: 2014]. [5] Sourceforge, “PHP iCalendar”, URL: http://sourceforge.net/projects/ phpicalendar/. Últim accés: 2014]. Ruby sobre rfc2245 [6] Rubyforge, “icalendar”, URL: http://icalendar.rubyforge.org/. Últim accés: 2014]. Java [7] “ICal4j Wiki”, URL: http://ical4j.sourceforge.net. Últim accés: 2014]. [8] Google, “caldav4j - A CalDAV client-library for Java - Google Project Hosting”, URL: http://code.google.com/p/caldav4j/. Últim accés: 2014]. Drupal [9] Drupal, “Views iCal - Drupal.org”, URL: https://drupal.org/project/views_ical. Últim accés: 2014].

59 Capítol 11. Bibliografia

[10] Drupal, “Date iCal- Drupal”, URL: https://drupal.org/project/date_ical. Últim accés: 2014]. Drupal [11] Drupal, “iCal - Drupal”, URL: https://drupal.org/project/ ical. Últim accés: 2014]. Wordpress [12] WordPress, “WordPress icalendar; WordPress Plugins”, URL: http://wordpress. org/plugins/tags/icalendar. Últim accés: 2014]. [13] WordPress, “WordPress iCalendar Events Widget; WordPress Plugins”, URL: https: //wordpress.org/plugins/icalendar-events-widget/. Últim accés: 2014]. [14] Marcus Sykes, “Using the iCal Feeds - Events Manager for WordPress”, URL: http: //wp-events-plugin.com/documentation/event-ical-feeds/. Últim accés: 2014]. Perl [15] Rich Bowen, “Date::ICal - search.cpan.org”, URL: http://search.cpan.org/~rbow/ Date-ICal-2.678/lib/Date/ICal.pm. Últim accés: 2014]. [16] Shane Landrum, “Net::ICal - search.cpan.org”, URL: http://search.cpan.org/~srl/ Net-ICal-0.15/lib/Net/ICal.pm. Últim accés: 2014]. [17] Rick Frankel, “iCal::Parser - search.cpan.org”, URL: http://search.cpan.org/ ~rfrankel/iCal-Parser-1.16/lib/iCal/Parser.pm. Últim accés: 2014]. Python [19] Plone Foundation, “icalendar 3.6.2 : Python Package Index”, URL: https://pypi. python.org/pypi/icalendar. Últim accés: 2014]. [20] Ian Lewis, “django-ical 1.2 : Python Package Index”, URL: https://pypi.python. org/pypi/django-ical. Últim accés: 2014]. [21] “Internet Calendaring and Scheduling (iCalendar) for Python; icalendar 3.0dev docu- mentation”, URL: http://icalendar.readthedocs.org. Últim accés: 2014]. Javascript [22] Philipp Kewisch, “mozilla-comm/ical.js · GitHub”, URL: https://github.com/ mozilla-comm/ical.js/. Últim accés: 2014]. [23] Keith Wood, “jQuery iCalendar”, URL: http://keith-wood.name/icalendar.html. Últim accés: 2014]. Validador [24] mozilla-comm, URL: http://mozilla-comm.github.io/ical.js/validator.html. Últim accés: 2014]. [25] Steven N. Severinghaus, “iCalendar Validation”, URL: http://icalvalid.cloudapp. net. Últim accés: 2014]. Doc

60 Capítol 11. Bibliografia

[26] John MacFarlane, “Pandoc - About pandoc”, URL: http://johnmacfarlane.net/ pandoc. Últim accés: 2013]. [27] joe di castro, “markdown”, URL: http://joedicastro.com/pages/markdown.html. Últim accés: 2013]. [28] Greg Schueler, “Quick Markdown Syntax Guide”, URL: http://greg.vario.us/doc/ markdown.txt. Últim accés: 2013]. Servidors [29] “mod_caldav - Free software downloads at SourceForge.net”, URL: http: //sourceforge.net/projects/modcaldav mòdul per a servidors Apache. Últim accés: 2014]. [30] Wikipedia, “CalDAV - Wikipedia, the free encyclopedia”, URL: http://en.wikipedia. org/wiki/CalDAV. Últim accés: 2014]. [31] Wikipedia, “Calendar and Contacts Server - Wikipedia, the free encyclopedia”, URL: http://en.wikipedia.org/wiki/ICal_Server. Últim accés: 2014].

61 Capítol 12

Cost del projecte

62 Capítol 13

Annex

13.1 Introducció

En aquest document hem treballat les necessitats actuals d’agenda i les possibilitats que ofereix la RFC5545.

13.2 Propietats de l’event

13.2.1 Propietats requerides i d’una ocurrència

dtstamp: especifica la data i hora en que es va crear l’event. En cas de revisió especifica la data i hora de la últim revisió

Exemple:

DTSTAMP : 19971210T080000Z

uid: identificador únic a nivell global. Cal que el generador garantitzi que el identificador és únic

Una manera recomanada és: datahora_creacio + num_sequencial + @ + nom_de_domini

Exemple:

UID:[email protected]

63 Capítol 13. Annex

dtstart: propietat que especifica quan comença el component. El tipus del valor és data i hora

Exemple:

DTSTART : 19980118T073000Z

13.2.2 Propietats opcionals però només una ocurrència

class: defineix la classificació d’accés de seguretat al component (PUBLIC / PRIVATE / CONFIDENTIAL)

Exemple:

CLASS:PUBLIC

created: hora i data de creació del component

description: descripció més amplia que la de la propietat summary

geo: especifica la geoposició global

Exemple:

GEO:37.386013;-122.082932

last-mod: data i hora de la última modificació del component

location: especifica el lloc on es celebra el event. Hi ha diferents opcions incloent una representació alternativa on es pot especificar una url LDAP [RFC4516] o una url CID [RFC2426] on trobem una vCard.

Exemple:

LOCATION:Avinguda Diagonal 1, Edifici 1

LOCATION;ALTREP="http://exemple.com/edifici1.vcf": Avinguda Diagonal 1, Edifici 1

64 Capítol 13. Annex

organizer: organitzador de l’acte

priority: permet definir la prioritat de 0 a 9

seq: nombre de la revisio del event, cardinal incremental.

status: especifica l’estat general o de confirmació del component.

TENTATIVE - provisional CONFIRMED - confirmat CANCELLED - cancel·lat

summary: curt resum de l’event.

url: especifica una url associada al event.Podria ser una interpretació més dinàmica del event.

13.2.3 Propietats opcionals però no haurien de tenir més d’una ocurrència

rrule: especifica la recurrència, detallat en aparts capítols posteriors

13.2.4 Propietats de final d’event

Per escpecificar el fi d’un event es pot usar o una data de final o la duració.

dtend: especifica la data o la data i hora de fi de l’event

duration: duració de l’event

Exemple:

Duració de 1 hora 0 minuts i 0 segons DURATION:PT1H0M0S

Duració de 15 minuts DURATION:PT15M

65 Capítol 13. Annex

13.2.5 Propietats opcionals amb múltiple ocurrència

attach: permet adjuntar documents, a partir de una uri o codificant en línia el document

categories: permet definir les classificacions associades al event

Exemple:

CATEGORIES:Cultura,Concert

CATEGORIES:Esports,Atletisme

comment: informació no processable, comentaris per al responsable del calendari

contact: informació de contacte de l’event, que pot ser text lliure o una url a una vcard

exdate: dates excloses en cas de recurrència, comentat en parts posteriors

rstatus: defineix el codi d’estat retornat per una petició de programació de l’event

related: relació amb un altre event del calendari

resources: equip o recursos previstos per a l’event

rdate: permet definir recurrència, detallat en capítols posteriors

x-prop: podem definir les propietats que vulguem prefixant amb ‘X-’. Es refereix a propietats no estàndards. És de tipus TEXT.

iana-prop: defineix propietats registrades per IANA

Exemple:

DRESSCODE:CASUAL NON-SMOKING;VALUE=BOOLEAN:TRUE

66 Capítol 13. Annex

13.3 Components de recurrència

13.3.1 Regles de recurrència

S’han de poder definir patrons de recurrència per als actes. Com que la complexitat dels horaris d’actes està en el seu nombre de possibles casos, ens plantejarem aquí tots els possibles.

Exemple: Tots els casos assumeixen la zona horària de Madrid.

Cada dia fins a 10 vegades (ocurrències)

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=DAILY;COUNT=10

==> (1997 9:00 AM EDT) Setembre 2-11

Cada dia fins al 24 de Desembre del 1997:

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z

==> (1997 9:00 AM EDT) Setembre 2-30;Octubre 1-25 (1997 9:00 AM EST) Octubre 26-31;Novembre 1-30;Desembre 1-23

Cada dos dies i per sempre

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=2

==> (1997 9:00 AM EDT) Setembre 2,4,6,8...24,26,28,30; Octubre 2,4,6...20,22,24 (1997 9:00 AM EST) Octubre 26,28,30; Novembre 1,3,5,7...25,27,29; Desembre 1,3,...

Cada 10 dies i 5 vegades

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5

==> (1997 9:00 AM EDT) Setembre 2,12,22; Octubre 2,12

67 Capítol 13. Annex

Cada dia durant el mes de Gener durant 3 anys

DTSTART;TZID=Europe/Madrid:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z;BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA o també RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1

==> (1998 9:00 AM EST) Gener 1-31 (1999 9:00 AM EST) Gener 1-31 (2000 9:00 AM EST) Gener 1-31

Cada setmana 10 vegades

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=WEEKLY;COUNT=10

==> (1997 9:00 AM EDT) Setembre 2,9,16,23,30;Octubre 7,14,21 (1997 9:00 AM EST) Octubre 28;Novembre 4

Cada setmana fins el 24 de Desembre del 1997

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

==> (1997 9:00 AM EDT) Setembre 2,9,16,23,30; Octubre 7,14,21 (1997 9:00 AM EST) Octubre 28; Novembre 4,11,18,25; Desembre 2,9,16,23

Cada 2 setmanes per sempre (en aquest exemple WKST indica el dia que comença la setmana)

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU

==> (1997 9:00 AM EDT) Setembre 2,16,30; Octubre 14 (1997 9:00 AM EST) Octubre 28; Novembre 11,25; Desembre 9,23 (1998 9:00 AM EST) Gener 6,20; Febrer 3, 17 ...

68 Capítol 13. Annex

Cada setmana dimarts i dijous durant 5 setmanes

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH o també RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH

==> (1997 9:00 AM EDT) Setembre 2,4,9,11,16,18,23,25,30; Octubre 2

Cada 2 setmanes els dilluns, dimecres i divendres fins el 24 de Desembre del 1997 començant el 1 de Setembre del 1997

DTSTART;TZID=Europe/Madrid:19970901T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; BYDAY=MO,WE,FR

==> (1997 9:00 AM EDT) Setembre 1,3,5,15,17,19,29; Octubre 1,3,13,15,17 (1997 9:00 AM EST) Octubre 27,29,31; Novembre 10,12,14,24,26,28; Desembre 8,10,12,22

Cada 2 setmanes els dimarts i dijous, 8 vegades

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH

==> (1997 9:00 AM EDT) Setembre 2,4,16,18,30; Octubre 2,14,16

El primer divendres de cada mes 10 vegades

DTSTART;TZID=Europe/Madrid:19970905T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR

==> (1997 9:00 AM EDT) Setembre 5;Octubre 3 (1997 9:00 AM EST) Novembre 7;Desembre 5 (1998 9:00 AM EST) Gener 2;Febrer 6;Març 6;Abril 3 (1998 9:00 AM EDT) Maig 1;Juny 5

El primer divendres de cada mes fins el 24 de Desembre del 1997

69 Capítol 13. Annex

DTSTART;TZID=Europe/Madrid:19970905T090000 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR

==> (1997 9:00 AM EDT) Setembre 5; Octubre 3 (1997 9:00 AM EST) Novembre 7; Desembre 5

Cada 2 mesos el primer i últim diumenge, 10 vegades

DTSTART;TZID=Europe/Madrid:19970907T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU

==> (1997 9:00 AM EDT) Setembre 7,28 (1997 9:00 AM EST) Novembre 2,30 (1998 9:00 AM EST) Gener 4,25;Març 1,29 (1998 9:00 AM EDT) Maig 3,31

Cada mes el penúltim dilluns durant 6 mesos

DTSTART;TZID=Europe/Madrid:19970922T090000 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO

==> (1997 9:00 AM EDT) Setembre 22;Octubre 20 (1997 9:00 AM EST) Novembre 17;Desembre 22 (1998 9:00 AM EST) Gener 19;Febrer 16

Cada mes 3 dies abans de que acabi el mes per sempre

DTSTART;TZID=Europe/Madrid:19970928T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3

==> (1997 9:00 AM EDT) Setembre 28 (1997 9:00 AM EST) Octubre 29;Novembre 28;Desembre 29 (1998 9:00 AM EST) Gener 29;Febrer 26 ...

El dia 2 i 15 de cada mes 10 vegade

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15

==> (1997 9:00 AM EDT) Setembre 2,15;Octubre 2,15 (1997 9:00 AM EST) Novembre 2,15;Desembre 2,15 (1998 9:00 AM EST) Gener 2,15

70 Capítol 13. Annex

Primer i últim dia de mes 10 vegades

DTSTART;TZID=Europe/Madrid:19970930T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1

==> (1997 9:00 AM EDT) Setembre 30;Octubre 1 (1997 9:00 AM EST) Octubre 31;Novembre 1,30;Desembre 1,31 (1998 9:00 AM EST) Gener 1,31;Febrer 1

Cada 18 mesos del 10 al 15 de mes, 10 vegades

DTSTART;TZID=Europe/Madrid:19970910T090000 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,15

==> (1997 9:00 AM EDT) Setembre 10,11,12,13,14,15 (1999 9:00 AM EST) Març 10,11,12,13

Cada dimarts cada 2 mesos

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU

==> (1997 9:00 AM EDT) Setembre 2,9,16,23,30 (1997 9:00 AM EST) Novembre 4,11,18,25 (1998 9:00 AM EST) Gener 6,13,20,27;Març 3,10,17,24,31 ...

Cada any al Juny i Juliol 10 vegades (s’especifica el dia en DTSTART quan s’usa BYDAY, BYMONTHDAY o BYYEARDAY )

DTSTART;TZID=Europe/Madrid:19970610T090000 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7

==> (1997 9:00 AM EDT) Juny 10;Juliol 10 (1998 9:00 AM EDT) Juny 10;Juliol 10 (1999 9:00 AM EDT) Juny 10;Juliol 10 (2000 9:00 AM EDT) Juny 10;Juliol 10 (2001 9:00 AM EDT) Juny 10;Juliol 10

Cada 2 anys Gener, Febrer i Març, 10 vegades

71 Capítol 13. Annex

DTSTART;TZID=Europe/Madrid:19970310T090000 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3

==> (1997 9:00 AM EST) Març 10 (1999 9:00 AM EST) Gener 10;Febrer 10;Març 10 (2001 9:00 AM EST) Gener 10;Febrer 10;Març 10 (2003 9:00 AM EST) Gener 10;Febrer 10;Març 10

Cada 3 anys els dies 1, 100 i 200 dels anys, 10 vegades

DTSTART;TZID=Europe/Madrid:19970101T090000 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200

==> (1997 9:00 AM EST) Gener 1 (1997 9:00 AM EDT) Abril 10;Juliol 19 (2000 9:00 AM EST) Gener 1 (2000 9:00 AM EDT) Abril 9;Juliol 18 (2003 9:00 AM EST) Gener 1 (2003 9:00 AM EDT) Abril 10;Juliol 19 (2006 9:00 AM EST) Gener 1

Cada 20è dilluns de l’any, per sempre

DTSTART;TZID=Europe/Madrid:19970519T090000 RRULE:FREQ=YEARLY;BYDAY=20MO

==> (1997 9:00 AM EDT) Maig 19 (1998 9:00 AM EDT) Maig 18 (1999 9:00 AM EDT) Maig 17 ...

El dilluns de la setmana numero 20

DTSTART;TZID=Europe/Madrid:19970512T090000 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO

==> (1997 9:00 AM EDT) Maig 12 (1998 9:00 AM EDT) Maig 11 (1999 9:00 AM EDT) Maig 17 ...

Cada dimarts de Març,per sempre

72 Capítol 13. Annex

DTSTART;TZID=Europe/Madrid:19970313T090000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH

==> (1997 9:00 AM EST) Març 13,20,27 (1998 9:00 AM EST) Març 5,12,19,26 (1999 9:00 AM EST) Març 4,11,18,25 ...

Cada dimarts de Juny, Juliol i Agost, per sempre

DTSTART;TZID=Europe/Madrid:19970605T090000 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8

==> (1997 9:00 AM EDT) Juny 5,12,19,26;Juliol 3,10,17,24,31; Agost 7,14,21,28 (1998 9:00 AM EDT) Juny 4,11,18,25;Juliol 2,9,16,23,30; Agost 6,13,20,27 (1999 9:00 AM EDT) Juny 3,10,17,24;Juliol 1,8,15,22,29; Agost 5,12,19,26 ...

Cada divendres 13 per sempre

DTSTART;TZID=Europe/Madrid:19970902T090000 EXDATE;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

==> (1998 9:00 AM EST) Febrer 13;Març 13;Novembre 13 (1999 9:00 AM EDT) Agost 13 (2000 9:00 AM EDT) Octubre 13 ...

El primer dissabte després del primer diumenge de cada mes

DTSTART;TZID=Europe/Madrid:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13

==> (1997 9:00 AM EDT) Setembre 13;Octubre 11 (1997 9:00 AM EST) Novembre 8;Desembre 13 (1998 9:00 AM EST) Gener 10;Febrer 7;Març 7 (1998 9:00 AM EDT) Abril 11;Maig 9;Juny 13......

73 Capítol 13. Annex

Cada 4 anys el primer dimarts després de un dilluns de Novembre

DTSTART;TZID=Europe/Madrid:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; BYMONTHDAY=2,3,4,5,6,7,8

==> (1996 9:00 AM EST) Novembre 5 (2000 9:00 AM EST) Novembre 7 (2004 9:00 AM EST) Novembre 2 ...

El tercer cas en el mes d’un dimarts, dimecres o dijous, per 3 mesos

DTSTART;TZID=Europe/Madrid:19970904T090000 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3

==> (1997 9:00 AM EDT) Setembre 4;Octubre 7 (1997 9:00 AM EST) Novembre 6

El penúltim dia laborable del mes

DTSTART;TZID=Europe/Madrid:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

==> (1997 9:00 AM EDT) Setembre 29 (1997 9:00 AM EST) Octubre 30;Novembre 27;Desembre 30 (1998 9:00 AM EST) Gener 29;Febrer 26;Març 30 ...

Cada 3 hores des de les 9:00 a les 17:00 d’un dia

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z

==> (Setembre 2, 1997 EDT) 09:00,12:00,15:00

Cada 15 minuts 6 vegades

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6

==> (Setembre 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15

74 Capítol 13. Annex

Cada hora i mitja 4 vegades

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4

==> (Setembre 2, 1997 EDT) 09:00,10:30;12:00;13:30

Cada 20 minuts de 9:00 a 16:40 cada dia

DTSTART;TZID=Europe/Madrid:19970902T090000 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 or RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16

==> (Setembre 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, ... 16:00,16:20,16:40 (Setembre 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, ... 16:00,16:20,16:40 ...

Un exemple de data invàlida pel 30 de Febrer en el qual és ignorat

DTSTART;TZID=Europe/Madrid:20070115T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5

==> (2007 EST) Gener 15,30 (2007 EST) Febrer 15 (2007 EDT) Març 15,30

13.3.2 Recurrència de dies i períodes

Defineix els dies per a events recurrents, complementa a les regles en cas de dualitat es queda amb una. Exemple d’aquesta propietat:

RDATE:19970714T123000Z RDATE;TZID=Europe/Madrid:19970714T083000

RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,19960404T010000Z/PT3H

RDATE;VALUE=DATE:19970101,19970120,19970217,19970421, 19970526,19970704,19970901,19971014,19971128,19971129,19971225

75 Capítol 13. Annex

13.3.3 Dates d’excepció

Quan el acte sigui de tipus recurrent es podrà especificar quines dates han de ser excloses. Aquestes tindran prioritat sobre les definides en les regles de recurrència generals de l’acte.

Exemple d’aquesta propietat:

EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

76