Software Units punishment on Timers and Static Entities for OutSystems

Software Units punishment on Timers and Static Entities for OutSystems

  
Hi All,

My first post here :)  Since a few months I am using outsystems now and I love the ease of a lot of things.
Also I understand the fact that the amount of software units (SU) for certain elements differ between elements as some offer more added value than others.

From what I can find the number of software units for certain elements I found this topic:http://www.outsystems.com/NetworkForums/ViewTopic.aspx?TopicId=5397&Topic=How-do-we-count-Software-Units%3F

Some Examples for outsystems 6.0
- Send Email: 10 SU
- Screen Preparation: 15 SU
- SMS Screen: 150 SU
- Entity: 40 SU
- Static Entity: 320 SU
- Timer: 400 SU

Seems strange to me that Static Entities and Timers cost a lot of SU compared to (IMHO) more complex elements like SMS screen. It almost feels like being punished for using Static Entities and Timers. Should we avoid using those? What is the reason for that much software units on those elements.   

Also I found a remarkeble difference from the 5.1 platform:
- Static Entities in outsystems 5.1: 80 SU
- Static Entities in outsystems 6.0: 320 SU

Can anyone give arguments why Static Entities cost that much?

Regards,
Nico Lubbers









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

enigma wrote:
 
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 =)
 
Well, there's the full table available of what suff costs what SUs, so it is possible to figure out if it will fit if you plan ahead. And there are a lot of things that you can do to minimize SU usage as well, without really affecting the application (being careful with Roles is the biggest item I've found). I totally understand the need to reduce SU usage! A lot of my customers are on a tight budget and can either afford more SUs or they can afford to pay me, but not both. :D

J.Ja
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 van der zalm wrote:
The discussion about SU's is something that keeps comming back.

<SNIP>

Since I do can understand the reduce of SU usage, a small tip: take a look at the exceptions handlers and flows.
 
 
The discussion around SU's does keep coming back, not just here, but in conversations with my customers. The SU issue is very confusing to them as well, and it makes it harder for them to commit to a purchase because they are unsure of what they need to buy.

Good tip on SU reduction. Something I do is take away the auto generated Exception handling in every Action, and replace it with a single Exception handling flow that all Flows point to. It's little things like that which can make a big impact on SU usage, while not making the developer waste a lot of time trying to "work around" SUs.

J.Ja
Justin James wrote:
 
The discussion around SU's does keep coming back, not just here, but in conversations with my customers. The SU issue is very confusing to them as well, and it makes it harder for them to commit to a purchase because they are unsure of what they need to buy.
 
 
This is excatly the discussion point. It's hard to explain to the customer that he must pay a licence fee for users and the amount of code. Also a problem is that when using the ANP sizing the SU usage is always to low. So when you make a sizing and sell that to a customer with the amount of SU set in the sizing you're gonne get in trouble. Maybe the new platform licence will change that a little bit since the first licence start with 150.000 SU....


Justin James wrote:
 
Something I do is take away the auto generated Exception handling in every Action, and replace it with a single Exception handling flow that all Flows point to. It's little things like that which can make a big impact on SU usage, while not making the developer waste a lot of time trying to "work around" SUs.

That what I also do :)

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...)
Justin James wrote:
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
 
 Again you give the answer youself :). Now the licence start with the 150k minimum, but, beside of the fact they asked if it can be put in the community edition, selling a licence is very hard when it's start with the minimum of € 15.000 (I must say it can also be about the dutch :) ). Like Joost said, at smaller projects the cost get's higher so it's not really relevant to do the project with the OS.

But thats also regaring a subject that was earlier discussed on the forum about the yearly licence cost....

Kind regards,
Evert
Evert van der zalm wrote:
 
 Again you give the answer youself :). Now the licence start with the 150k minimum, but, beside of the fact they asked if it can be put in the community edition, selling a licence is very hard when it's start with the minimum of € 15.000 (I must say it can also be about the dutch :) ). Like Joost said, at smaller projects the cost get's higher so it's not really relevant to do the project with the OS.

But thats also regaring a subject that was earlier discussed on the forum about the yearly licence cost....

Kind regards,
Evert
 
 Eventually, I have my contract rates so high that the cost of a license looks small in comparison? :D

J.Ja
Justin James wrote:
 
 Eventually, I have my contract rates so high that the cost of a license looks small in comparison? :D

J.Ja
 
 LOL :)