Op mijn nieuw iPhone schakelde ik de belangrijkste functies voor zakelijk gebruik in: email (IMAP), en het synchroniseren van contacten en agenda. Deze diensten worden geleverd door servers in eigen beheer.

Voor het synchroniseren van contacten gebruik ik het CardDAV-protocol. Voor de agenda is een vergelijkbaar protocol dat CalDAV heet. Baïkal is de software waarmee dit op de server wordt gefaciliteerd, via webserver Nginx. De recente versies van iOS ondersteunen zowel IMAP, CardDAV als CalDAV. Mijn laptop synchroniseert de gegevens ook met deze server, met gebruikmaking van dezelfde protocollen.

Email en contacten waren snel geregeld op de iPhone. Synchronisatie van de agenda werkte niet meteen. Daarom maar even op onderzoek uit.

Zoeken op internet naar de combinatie van iOS en Baïkal levert een aantal specifieke probleemmeldingen op. Om een verder goed werkende Baïkal-service op iOS werkend te maken, moet in de webserver een aanpassing worden gemaakt. Bij het leggen van contact met de Baïkal-server gebruikt iOS een standaard pad, iets in de vorm van https://my.server.com/baikal/.well-known/caldav. Hiervoor moet een redirect-regel worden opgegeven in de webserver, die er voor zorgt dat het verzoek van de iPhone doorverwezen wordt naar het juiste adres.

De meeste documentatie van Baïkal gaat niet uit van Nginx als webserver. Los daarvan wordt in de voorgestelde oplossingen niet altijd duidelijk waar deze redirect-regels moeten worden doorgevoerd. Opties:

• In de root-folder van de website van de Nginx-server zou een directory .well-known moeten bestaan, met daarin een bestand genaamd .htaccess waarin de (Nginx-specifieke) redirect-regels moeten worden opgenomen. Dit bleek niet voldoende om een redirect te forceren.
• In de basis-configuratie van Nginx-server. Deze instelling zorgt dat het verzoek van de iPhone naar de goede url wordt doorverwezen.

Voorbeeld van redirect-regels voor Nginx in het .htaccess bestand:

rewrite ^/.well-known/carddav$ /card.php;
rewrite ^/.well-known/caldav$ /cal.php;

Voorbeeld van redirect-rules in de server-sectie in bestand /etc/nginx/nginx.conf:

server { listen 443; server_name my.server.com; root /var/www/baikal/html; index index.php; rewrite ^/.well-known/caldav /dav.php redirect; rewrite ^/.well-known/carddav /dav.php redirect; charset utf-8;

Na het doorvoeren van deze wijzing synchroniseerde de agenda nog steeds niet. Bij het invoeren van het adres van de Baïkal-server controleert iOS een paar zaken, en concludeert dat er geen agenda te bereiken is. In de Nginx access logs zijn op dat moment de binnenkomende verzoeken te zien, waarvan de laatste eindigen in http error 405 (method not allowed).

iOS stelt veel verschillende vragen aan de CalDAV-server, waarvan Baïkal niet alles lijkt te ondersteunen. Dergelijke foutmeldingen zijn dus niet helemaal te voorkomen, ook als synchronisatie wel werkt. Vanaf de iPhone kon de agenda echter nog niet worden gesynchroniseerd.

Het viel me op dat het opzetten van synchronisatie voor contacten via CardDAV geen enkel probleem had opgeleverd op de iPhone. Een analyse:

• De url die de Baïkal-server verwacht voor de contacten is standaard https://my.server.com/baikal/card.php/addressbooks/erwin/default/
• In iOS was er dit van gemaakt (werkend): https://my.server.com/baikal/card.php/principals/erwin
• Bij het opzetten van synchronisatie van de agenda verwacht iOS: https://my.server.com, en stelt de vraag vervolgens aan https://my.server.com/baikal/.well-known/caldav.
• Dit leidt tot redirect naar https://my.server.com/baikal/cal.php/addressbooks/erwin/default/ en tot foutmeldingen.
• Daarom heb ik het volgende als adres ingegeven bij de iOS-agenda: https://my.server.com/baikal/cal.php/principals/erwin. Dit werkt.

Dus, voor synchronisatie van contacten en agenda op iOS met een Baïkal-server op Nginx:

• De redirect-regels (voor iOS) moeten in orde zijn op Nginx, dus in de basisconfiguratie van Nginx.
• De url’s die in iOS moeten worden ingegeven voor de Baïkal-diensten wijken af van wat gebruikelijk is met andere Baïkal-clients.

Since a few weeks, I am using an iPhone as business smartphone.

This has a long history. For quite some time, I have been using Nokia smartphones with Symbian. First, the N95, and later some of its successors. Their specifications were never best in class, and configuring them required quite a lot of work. But, they generally met my requirements for a business smartphone. Then came a robust Samsung Galaxy S4 Active and later an S6. Many of their functions work perfectly, as long as you want to use the Google prepared solutions. Until recently, I have been using a Jolla, using SailfishOS, which can be considered a descendant of Symbian. Its specifications were mediocre. Still, email and the calendar used to work fine. Later, the device was showing a number of issues, which were difficult to grasp, but recurring. This became so elaborate that I decided to look for another smartphone.

For business use, my requirements are modest. Email, calendar and contacts need to be available. The smartphone is only one of the devices, so everything must be kept synchronized, using various accounts. The most important central functions (email, synchronization) is hosted on my own servers.

Additionally, it would be convenient to have some other functions available when on the road: taking pictures, social media, etc. For this, I considered two alternatives: a separate tablet next to the (simple) smartphone. Or, a single smartphone that can do all. I decided for a large iPhone 7 Plus, which can do it all. Android is not my preferred smartphone operating system. Windows smartphones provide value for money, but Windows appears to become marginal. A smartphone running something different from Android, Windows or Apple’s iOS is not available, currently.

So, what is the verdict after a few weeks of using? The device is easy to use. It is surprising how quick and easy configuration is done. Having a powerful smartphone with a nice display and a good camera is of course very nice. After a few weeks, the last issue regarding the business functions has been resolved: calendar synchronization.

Sinds enkele weken is het zo ver: ik heb een iPhone als zakelijke smartphone.

Hier is een hele geschiedenis aan vooraf gegaan. Lange tijd heb ik Nokia-smartphones met Symbian gebruikt. Om te beginnen de N95, en daarna nog wat opvolgers. Ze waren nooit de top qua specificaties en ze vroegen flink wat inrichtingswerk. Toch waren ze prima voor de zakelijke functies die ik waardeer. Daarna kwam er een waterdichte Samsung Galaxy S4 Active en later ook nog een S6. Veel functies werken vlekkeloos, zolang je de Google-oplossingen wenst te gebruiken. Tot voor kort gebruikte ik een Jolla, met SailfishOS, dat de opvolger van Symbian genoemd kan worden. Het was een apparaat met middelmatige prestaties, maar email en agenda werkten prima. Het apparaat begon vage maar terugkerende problemen te vertonen, mogelijk door haperende hardware. Dat werd onwerkbaar, en daarom heb ik naar een vervanger gezocht.

Voor zakelijk gebruik zijn de eisen bescheiden. Ik wil mijn email, agenda en contacten kunnen gebruiken en beheren. De smartphone is een van de apparaten. Alles moet dus gesynchroniseerd worden, via diverse accounts. Het belangrijkste deel van deze gegevens is in eigen beheer, op eigen servers.

Dan is het natuurlijk ook wel handig om wat andere zaken onderweg te kunnen doen: foto’s maken, social media bijhouden, etc. Hiervoor heb ik twee opties overwogen: een aparte tablet naast de (eenvoudige) smartphone, of een enkele smartphone die het allemaal kan. Het is een grote iPhone 7 Plus geworden die het allemaal kan. Een Android-smartphone heeft niet mijn voorkeur. Smartphones met Windows zijn goed geprijsd, maar Windows lijkt terrein te verliezen. Buiten Android, Windows en Apple’s iOS is er geen serieuze smartphone te koop.

Wat is het oordeel, enkele weken na ingebruikname? Gebruiksvriendelijkheid is prima. Het is verassend hoe snel en makkelijk bepaalde zaken in te schakelen zijn. Het is fijn om een snelle smartphone te hebben met een mooi scherm, goede camera, etc. Na enkele weken is het laatste pijnpunt voor zakelijk gebruik, synchronisatie van de agenda, ook opgelost.

HANA is veel dingen. Een eigen, in-memory, database manager van SAP AG met column store faciliteiten. Met daarbij een aantal nieuw-ontwikkelde componenten voor onder andere ERP, geavanceerde planning, Business Intelligence, Analytics, etcetera.

Wat is bijzonder aan de database manager van SAP HANA? In eerder artikelen is de uitdaging bij het ontwerp van database management software beschreven, en de kolom-georienteerde opslag die HANA gebruikt.

Een kolom-georienteerde tabel wordt in SAP HANA ook beschikbaar gemaakt in rij-georienteerde vorm. HANA zorgt zelf dat de rij- en kolom-versies van de tabel gelijk blijven lopen. En bij iedere mutatie van gegevens in een kolom-georienteerde tabel moeten beide versies worden bijgewerkt.

Nu: De delta-stores van SAP HANA.

Om de doorlooptijd van de muterende statements niet te veel te beinvloeden, wordt het bijwerken van rij- en kolom-versies door SAP HANA niet direct gedaan tijdens het uitvoeren van het muterende statement (bijvoorbeeld een SQL UPDATE-statement). Iedere mutatie op de inhoud van een tabel wordt in eerste instantie in een delta-store voor de betreffende tabel vastgelegd, waarna het statement voor de gebruiker is afgehandeld. In de achtergrond verwerkt SAP HANA de delta-store en werkt dan de rij- en kolom-versies van de tabel bij. Dit is het delta-merge proces.

Wanneer voor een tabel een mutatie verwerkt moet worden op een moment dat het delta-merge proces draait, dan is de delta-store niet beschikbaar. De mutatie wordt dan in een tweede delta-store geschreven om later in de rij- en kolom-versies verwerkt te kunnen worden.

Naast de extra benodigde opslagcapaciteit is een ander gevolg van het gebruik van delta-stores dat SAP HANA bij iedere operatie op de tabelinhoud zowel de beide delta-stores als de rij- of kolom-versie moet raadplegen.

Ingewikkeld? De column store maakt spectaculaire versnelling van queries op grote gegevensverzamelingen mogelijk. Het gebruik van de delta-stores voorkomt dat het extra rekenwerk ten koste gaat van de performance van de muterende bewerkingen. Het gaat om grote databases die intensief worden gebruikt. Daarbij is een efficiente oplossing nodig voor lees- en schrijfacties die tegelijkertijd op dezelfde gegevens kunnen plaatsvinden. Multi version concurrency control.

HANA is many things. It is an own, in-memory database manager with columnar store by SAP AG. Including a number of newly-developed components for ERP, advanced planning, Business Intelligence, Analytics, etcetera.

What is special about SAP HANA’s database management system? In earlier articles, the key challenge of designing contemporary database management software has been described, as well as the column oriented store used by HANA.

All column oriented tables are also made available in row oriented form by SAP HANA. HANA takes care that the row and column oriented versions of a table are kept in sync. Changes to the data require extra work to update both the row and the column store.

Now: The SAP HANA delta-stores.

In order to avoid impacting the run time of data changing operations too much, SAP HANA does not immediately update the row and column versions of a columnar tabular upon posting the changes (for example an SQL UPDATE-statement). Every change to the table’s content is initially saved to a delta-store for that table, after which the change statement is complete for the requester. In the background, SAP HANA processes the delta-store and updates row and column versions of the table. This is the delta merge process.

When another change to the data has to be processed at the moment the delta merge process is active, the delta store is not available. The change is then stored in a second delta store for the same table, so that it can be processed into the row and table versions at a later stage.

Next to additional storage space used, another consequence of using delta stores is that upon every request for table content, SAP HANA has to consult both delta stores as well as the row and column versions of the table.

Complicated? Using a column store makes dramatic improvements to the speed of queries on large data sets possible. The delta-stores prevent the cost of extra updates from slowing down the data changing operations. This is about large databases which are used intensively. For that, an efficient solution is required where reading and writing operations on the same data at any moment. Multi version concurrency control.