Typical Outsystems Development Errors : Preventing, Identifying and Resolving

Typical Outsystems Development Errors : Preventing, Identifying and Resolving

Hi everyone, i would like to suggest that this area aggregates typical errors that come from development and delay the works...If there is already anything like it, please say so.
My idea is : If we can list'em we are better prepared to prevent'em ;-)

Here is my first contribute to this list

Syntax Errors in Advanced Queries :

Prevent : Always test the advanced queries when possible (sometimes with INSERTs, updates and deletes, it is not possible...)
Identify : Usually the best way is to read the first and final words on the SQL error message (The first indicate the query, and the last the syntax error). This can be done either on the screen or in Service Center Error Logs.
Some Typical Errors
  The output parameter expected is not of the same type as the one being returned by the query
  Not All the parameters in the Select are in the Group By

First, Nice initiative Diogo!

Download action doesnt Download at all

Prevent : Download widget have to be triggered by a Submit (post) to work properly.
Identify : Verify the method type of your Button / Link.
Diogo -

Interesting idea!

Prevent: Not sure what the cause of a compilation error is for an extension.
Identify: There are two error messages listed in the "Publish" dialog; clicking the the one higher in the list displays the error.

Prevent: Actions performed on widgets with Display = False does not seem to work.
Identify: Set Display = True, and set the widget to have a style of "display: none"; widgets set to "Display = False" do not appear in the output at all.

This is actually harder than it looks... I really don't have any common mistakes I make. Those two above are the only ones I can remember driving nuts for more than a few minutes, unless you include the bizarre stuff that's happened in Integration Studio writing code by hand...

This is a great idea - and a difficult one to accomplish. Let me chip in with something - three related tips that, if my mind doesn't trick me, are the following:

Prevent: Make sure each timer action execution is supposed to run for a short amount of time (default timeout is 15 minutes)
Identify: Timer action seems to go off, but logs a timeout in Service Center Error Log.
Resolve: If you're executing timers to do bulk, long processing of data, or logic (i.e. sending e-mail campaigns, doing data backups, processing thousands of records),
1 - Create an entity that stores the status of the timer action (for instance, the last contact that was e-mailed)
2 - In the timer action, start by checking if there's anything to process. If there is, then start from the last one that was executed, and execute just a finite amount of cycles/tasks (i.e. 100 e-mails, records, etc., for instance).
3 - After those tasks are finished, update the status in the entity, and call the WakeTimer action to restart the timer, and continue from where you left off.


Prevent: Don't do long processing of data in Screen Actions (or user actions being invoked in a web request). Once again, the web request timeout will abort all that you are doing.
Identify: You'll get an exception, after a long web request.
Resolve: Do it asynchronously, in a timer action. Worst case scenario, you'll have to create an entity where you store the arguments that the timer has to use. Work it like a stack/queue - i.e. retrieve the arguments, and when you finish processing, remove them from the list. Once again, at the beginning of the timer action, check if there's anything to process :)


Prevent: Slow SQL updates/creates or deletes when doing mass updates/creates/deletes;
Identify: Any time you have a cycle that, on each iteration, executes a create/update/delete. I'm talking about hundreds or thousands here.
Resolve: If you expect to iterate a lot of records, then:
1 - On each iteration, instead of executing the entity action, append text to a string for an Advanced Query that does what you're trying to accomplish. Use a StringBuilder to optimize the memory use and speed, if you expect to store thousands of SQL instructions in a single query (I'm pretty sure our Text extension in Enterprise Manager uses it for concatenations).
2 - At the end of the iterations, execute an Advanced Query with the query string you created. You have to set the parameter to Expand Inline for it to work that way, if I recall correctly.
3 - Do TEST the query you're executing extensively, since you are generating a query in runtime, and executing it by hand. Remember to separate the instructions, to escape all content, to use the quotes for the strings, etc.


Well, and that's it! Hopefully this helps someone :)


Paulo Tavares