Moin xRes developers,
First of all THANK YOU for taking part and supporting the process of
technical development of xRes and its infrastructure. I feel very glad
to see You interested and active in this area. After several years this
process of technical improvements was successful, but often handled
unplanned and based on the engagement of single developers. But we
reached (in example) the following aims:
* using HHVM and PHP 7 in production
* running xRes on CentOS
* setting up a new xRes installation within only a few days
* scaling service, data and cache machines to almost unlimited ressources
* refacturing a huge part of xRes code
* adding (since January 2014) UnitTesting to xRes: Tests: 6445,
Assertions: 25715
* and MUCH more ...
For the year 2019 we did today talk about the following topics to be
done / solved / planned:
1. We will finish to move old service01/02 Debian systems to new
_*CentOS*_ machines.
-> default PHP version will be 5.6
-> _*Bamboo*_ build process MUST be migrated to PHP 5.6 or 7.1 (or
both) BOFORE to run UnitTests with new MongoDB driver
-> _*MongoDB diver*_ must be replaced under PHP 5.6 within an xRes
release (it is not compatible to PHP 7)
-> after that default _*PHP*_ version can be switched to _*7.1*_
-> all xRes customers (except LMX) will move to _*ServiceXY.BC*_
booking clusters ... only LMX gets dedicated ressources
2. Currently _*ZendFramework 1 does NOT support PHP 7.2*_. We'll need a
solution for this problem considering PHP 7.1 is supported until end
of 2019.
3. Is it helpful to _*split xRes git repository*_ into separate repos?
We'll have a developer meeting about this in January 2019.
4. Rene mentions existing problems in the _*structure of booking in
xRes database*_. In a "Mittwochs-Session" he will present these
problems and we'll discuss possible solutions and the advantages /
disadvantages and costs.
5. Currently _*logging and monitoring*_ are a mess in xRes code and in
TraSo infrastructure. We will have another "Mittwochs-Session"
prepared by Viktoras to discuss about:
-> How can developers use NEW code structures / adapters /
interfaces and help cleaning up inhomogeneous logging structure in xRes.
-> How can and should a future logging infrastructure look like?
What technical requirements do we know about a future logging solution?
-> Which requirements do xRes customers and TraSo management have on
monitoring for technical and business monitoring of xRes systems?
6. _*Dependency Injection Container*_ => Georgii will prepare a
"Mittwochs Session" to show xRes developers the usage of a DIC while
refactoring existing code in a live demonstration.
7. The current _*xRes database deployment system*_ based on
phing/dbdeploy has serveral disadvantages. Jacob will present pingx
as a possible solution for these problems. I will ask Felix to add
his experience writing an own db deployment for xMid 1.5 years ago.
8. For several reasons we could need another system to run
non-webserver jobs we currently start as "CRON". Requirements for
such a _*new CronJob system*_ are i.e. dependency jobs (start job B
when job A is ready), a more than minutely running job (i.e. all 30
seconds or more often) and a GUI based scheduling (start a job on
click, see job status, kill a job, ...).
9. Starting with new xRes customers SIT, RZP and SAR we are
accidentially _*using MariaDB*_ from CentOS repository as xRes
database ... and we will soon see if this works or if we broke a
hell loose. But to be "in time" with current versions of MySQL we
should be abled to use
-> MySQL 5.6 / 5.7 or 8.0,
-> MariaDB 10.2 or 10.3 or
-> PerconaDB 5.6
In case of PerconaDB we SHOULD take care about the frequently
appearing problem of _*DB fragmentation*_ we see i.e. in CacheDb
systems.
10. The whole xRes system was setup and is still running in _*ISO-8859
Latin-1 encoding*_. Again and again we are having problems
converting this stuff to UTF8 or from external UTF8 to Latin-1 and
backwards. Our customers submit MANY tickets in context of encoding
problems, wrong displayed informations or booking problems related
to destroyed traveller names. We SHOULD finally solve this problem.
In addition xRes is on some places of xAdmin abled to be used
multilingual ... but this functionality does currently not cover all
xAdmin pages and is not implemented in xRes booking core at all.
11. Since the feature of DSGVO+PRRL in summer 2018 we use Redis as a
caching system for xRes booking data. On some xRes installations a
separate Redis service is used, customers running on service booking
cluster already use a shared Redis cluster (because of a newer
driver in higher PHP version). After point 1 on top of this mail we
should monitor the state of this Redis infrastructure and bring ALL
xRes installations to run on the central _*Redis cluster*_.
12. Since decades an xRes booking has ONE status for the whole booking.
Neither any selling plattform nor a midoffice system handles
bookings this way ... all of them require a status per service (i.e.
per hotel, flight or transfer). We are getting more and more
problems matching this global status per booking from and to service
status ... and we finally should introduce _*a status for every
single service in a booking*_.
13. The hotel providers GTA and TOUR have been bought by another hotel
provider company Hotelbeds HBD. HBD communicated, the offers
currently imported and booked via GTA and TOUR gateways will one day
be available via HBD booking gateway only. I am very looking forward
to _*deactivation of the GTA import servers*_ we had to setup to
manage the import process GTA provides.
Please now:
* Give me (to the developers list) feedback about these topics. How do
YOU prioritize the topics? Which topics can YOU help to solve?
* Add one, two, many of the important, urgent or just interesting
topics we have NOT been abled to talk about in todays meeting.
BG SRK
--
Mit freundlichen Grüßen
Stefan Rank-Kunitz
- Technical Director -
________________________________________________________
TraSo GmbH
Nonnenstraße 42
D-04229 Leipzig
Tel.: +49 341 355 740 - 43
E-Mail: s.rank-kunitz(a)traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850
