Hello Nico,

Don't know the real answer (since I don't work at OS), but I think it's related to the complexetiy of the needed code. A static entity and timer are simple to use in OS but the needed generated code would be more and also more complex. Something like that?

Kind regards,
Evert

I would think of more software units are calculated with increasing complexity, but that is exactly the point of my post.
A static entity is just a simple thing. Something like constants. They repesent a value at compile time. Why would that be complex?

Hello Nico,

Thats what OS need to answer :).

In mine opion (and expercience) you should only use a static enty if you're shure nothing is gonne change quickly, like countries or gender. I've see it to many times that at the end new static attributes are needed, which implement a code change instead of input change.

Kind regards,
Evert

Hi Nico,

I like to think on the number of SUs of each element being related to the amount of work (and risk) it saves you from in case you'd be doing it with manual code.
In the case of the static entities, they're not just constants. They can be used as constants, but have a direct mapping on the database, which can even be translated to several locales in Service Studio. The platform handles all the queries to those entities, in a multilanguage level. On top of that it handles, without you even noticing, the caching of those entities for some scenarios. Last... but not least, it handles all the staging (DDLs and data) for those entities accross environments, so you don't need to worry with making backoffices or data scripts when publishing from DEV to QA to PROD. It saves you this work, and does that with TrueChange, ensuring you don't delete an entry you're already using... In regards with the SU's change from 5.1 to 6.0, it is related to the fact that a static entity Record on 5.1 was much higher than it is in 6.0. So, it was considered that in static entities, a list of countries for example, the number of countries you manage in the platform, is not as relevant as having an actual list of countries that is fully managed for you. So we weighted both (increased on entity, decreased on records) towards a more fair number as you add more records.

In the case of the Timers, they're really very valuable. Considering you have full queuing management (ensuring that timers run in sequence to not bog down the server), you can define a schedule for a timer to run, give it a timeout for automatic exception handling and abort of longer than expected processes, being able to manage and change these settings at runtime in Service Center.. On top of that, if you have several frontend servers, the platform will automatically garantee that, even accross the several servers, the same timer is not run in parallel (which might cause invalid code to run). The full multithreaded/multi-server complexity that the platform handles on the Timers is something that would be extremell hard to do in case you needed to create a set of assynchronous jobs, that can live among each other and accross servers for the entire lifetime of the applications...

cheers
Gonçalo

I really don't think it matters what they "cost". If you are choosing something over a static entity just for the sake of saving some SUs, you are doing it wrong. If you choose to not use a Timer in favor of something else... well... you're doing it wrong. What would you rather do, spend 400 SUs? Or write some batch process to be called by Task Scheduler or cron or whatever to call up a page that is going to do what the timer would do? If 400 SUs are worth more to you than your time to work around it, your time has a low value indeed!

The way I see it, if I'm pushing the limits of my license, chances are I have an application so big, that to do it in another system would have cost so much more in development costs than an Agile Platform license. AP has awesome ROI when you sit down and run the numbers.

J.Ja

where JJa is right, hes right =)

i used the comunity edition to make a tool for work (my boss isnt yet ready to accept outsystems or a "new" tool in general)
this tool basically takes care of must anoying administrative work

i needed roughly two weekends to develope it
and it easily saves me 30-60min/week

if i would have had to create the same tool with php or .net
i would have spent ages in developing and debugging it
plus the administrative work i could have saved in that time

some might think at theis point: "ok but i only have to develope it once"
these people might just need some more experience;
as everything changed with time, you will need application modifications sooner or later  
but theres one point im not so happy about: the transparency of the needed software units
ie. you have X'000 units left and you are intending to create a new feature or similar
you will not know if you have sufficient units, unless you try and possibly even waste the time =)

Wow.. thanks for these extensive replies. This is putting things in better perspective for me :-)
Cheers, Nico

The discussion about SU's is something that keeps comming back.

I totally agree with the post of Justin. Just keep the advantage of the platform instead of just trying to 'downsize' the SU's. How much time does it take you to keep track of minimizing the SU's and how much does that 'cost' for the customer?

Since I do can understand the reduce of SU usage, a small tip: take a look at the exceptions handlers and flows.

But still, I think it's a logic story for the boss. If the application grows, also the SU and therefore the price does :).

Kind regards,
Evert

Evert -

One thing I never do is provide any promises on SU usage. I can't predict SUs, let alone promise any. You are right that it is a lot easier with a minimum of 150k... I'm no longer hearing folks asking me to squeeze an app into a "Standard 60". But at the same time, I still hear folks asking me if something can be shoved into the Community Edition, and the answer is almost always "No".

J.Ja

Although I agree you cannot predict the number of SU's, it's a bit annoying the number of SU's is "calculated" in the sizing tool.
Not to mention, the increase of licence-costs if you happen to go outside the initial 150.
Perhaps in the world they don;t care about licence costs, in the Netherlands they are very very sensitive on licence costs.
(and for small projects it's at least 1/4th of the developmonts costs...)