Servoy Forum

When we started with Servoy in 2014, we used 7.4 to avoid any "teething problems" that the Servoy 8 might have had at that time.
We were very pleased with the stability and performance of 7.4 in the last five years. No downtime at all, in combination with PostgreSQL.

And although I like very much the wise saying "Never change a running system", I also know we can and should not stay forever on 7.4
Therefore I would like to ask about experiences regarding a move from 7 to 2019.X (or 8, if there are none for such a big "jump").
Was it easy or was a lot of fixing necessary?
Any problems with plugins?

Note: It will not be possible to create everything new for the NGClient.
We need to take over our smart client forms completely and want to stick to smart client.

Hi Bernd,

If you use table events, there was a change in the 8.x series which affected my systems. Code that had previously run fine would cause endless loops because of different records trying to update each other. This was caused by me forcing updates by setting the modified time stamp on records. The solution was to only set the timestamp if the related record was not already modified.

BTW. You do not need to create everything new for the NG-client. I converted a smart-client system with super-complicated forms to NG a year ago. 99% of the forms stayed the same. The model logic stays the same. The only changes were relating to running in a browser and not having direct access to the file system, printing, reports as downloads etc... You need a new style sheet (the app will look bad until you make a new one), but in NG you have much more control. You can have a headless client running on the server producing PDFs on behalf of the NG clients if need be...

Hope this helps,

Christian

Hi Bernd, so far, we came across, that we had to update jasper reports to the latest version.
For us it's not completely clear if we have to add the two spring jars to the jnlp still. On the servoyforge page there is nu info at all anymore for this..
see here: viewtopic.php?f=15&t=14445&start=15#p120752

Also we came across, that the mailPro plugin was not loaded correctly in Servoy 2019.12.
The issue was the embedded Java version 13? Patrick is going to fix it, but for now, we changed the Servoy.ini file, so that Servoy loads with the default OS java (in our case Java 8 )

We are still in the middle of it, as soon, as I have more info, I will let it know.

Harjo wrote:we came across, that we had to update jasper reports to the latest version.

Thank you all for the shared experiences.
Hm, we use iReport 5.5.0 and depend quite much on that.

Can that iReport version not be used any more in Servoy 2019.X?
Do you know why?
And which version do you use now?

the reason was (It think) because of the different POI jar files versions...
We simply had to upgrade to the latest version here: https://www.servoyforge.net/projects/se ... 2Cfilename
to get things working again.

We did'nt had to update the reports itself, just the plugin version.

In general it is a wise thing to update your 3th-party plugins to the newest version available at the vendor / publisher when you switch to Servoy 2019.
I believe we had to update 3 plugins in total.

Regards,

When upgrading in future, I think of a model where the old 7.4 Servoy server still works as usual for 90% of all users,
while just one smaller branch with 10% of the users would switch to the new 2019.X server -
while both servers use the same live postgres database.

The idea is that if there is a showstopper, it will not affect all users at once.
Would that be possible to run those two different servoy servers (old and new) with the same application on the same mutual database?

For sure I would need two different servoy repository databases, which means the new one would need renaming to be able to exist besides the old 7.4 repository.

The problem / challenge with 2 (or more) Servoy application servers on the same database is data broadcasting between the two and keeping the servoy sequence counters in sync between the two (if applicable).

Regards,

And basically, your are saying: I have no test scenario/budget/team, and I want to let my customers test for them selfs, right?
Like Lambert says: it can be done, but be aware of non working databroadcast/caching between the servoy servers, and you can't have servoy-sequences.

No sure we will test it before at length. However if it is possible to start slowly, I would always prefer that.
Because the full employment with all users can not be tested, at least not with justifiable costs.

Thanks for the caching remark, that might be an issue.
Looks like to ask all users to spend a bit time on a test server is a better approach.

We've always done parallel deployments when upgrading. Make sure you aren't using Servoy sequences, and you should generally be ok. There is no data broadcasting between servers as others have mentioned, but usually this isn't a showstopper. It only becomes a problem in a scenario like this: User A on new system views a record. User B on old System updates the same record. User A on new system views the record again, now User A maybe viewing cached/outdated data.

So, to get around this I usually try to group the client beta testers together if possible. Lets say its an order management system, take all the people that do phone orders and put them on the new system and put the people that do email orders on the old, or whatever make sense for your situation. Essentially keep users that are more likely to access the same records grouped together. If you have a multi-tenant system, then just do the 1 whole tenant.

To get around the data broadcasting you have a few options...
- Sledge Hammer: use flushAllClientsCache(serverName, tableName) on a scheduled batch processor. This will have a large performance impact and is generally avoided.
- Normal Hammer: use notifyDataChange(serverName, tableName, pksDataset, action) on a scheduled batch processor, by using raw SQL to search for modified data by timestamp (assuming you have a modified date in each table).
- Scalpel: Build a system to handle data broadcasting. Either your own pub/sub implementation using something like RabbitMQ to trigger notifications between servers, or by building web service endpoints in Servoy, and hit them in table events to communicate between servers. Servoy added native RabbitMQ in Servoy 8, but I don't think it was ever officially added to 7. Just be careful you don't get yourself in an infinite broadcasting cycle.

We are not fully done yet, however I already can say there were very few issues to solve.

The biggest advantage for smart client users seems to be that Servoy 2019 automatically scales up the application resolution to the actual screen size.
That way the application looks nice and large, independent of the screen resolution of the individual user.

My current résumé is that we should have done this more early.