Good summary.

Full Forms

OML: OutSystems Modeling Language.

XIF: External Integration File.

OAP: OutSystems Application Package.

OSP: OutSystems Solution Package.

What is LOW-Code?

What is low-code? Low-code is a way to design and develop software fast and with minimal hand-coding. It enables skilled people to deliver value more quickly and more reliably.

What are application objects?

Application objects are elements of your application:

• Pages: The screens you design or install in your environment for end users. These can include web screens, email screens, mobile web screens and SMS screens as designed in the visual development environment. For example, a pop-up web screen or a Supplier_List web screen each equals 1 application object.

• Tables: Entities that you design with Outsystems Platform or import for integration from external databases or both. Each Local Storage entity (applicable to mobile) will count 1 additional AO, regardless if it is a new entity or an existing one.

• API/Service operations: Methods from web services, REST APIs or integration connectors that you consume or expose. APIs in extensions, the C# code that you reuse in OutSystems Platform, are not accounted for.

What constitutes a page?

Pages are the web screens, email screens, mobile web screens, SMS screens as designed in the visual development environment. Web blocks are not pages, but screen components. Therefore they’re not counted.

When a single page includes multiple tabs, what is counted?

If each tab is implemented in a different web screen in the designer, they are different pages and each is an application object. If each tab is implemented in the same screen with web blocks or inline, they all constitute just 1 page or 1 application object.

What about pop-ups on a single page?

If the content of the popup is a different web screen, the screen in the popup is counted as a page and therefore is an application object. This is the default when you scaffold a popup or use Richwidgets popup components. 

Usually, a tiny help message will not have its own screen, but will instead be something like a tool tip and therefore is not counted as an application object. If the popup has some transactional logic, it is usually implemented in a different screen and therefore counts as an application object. The developer will decide the best design.

Hey good job Vijay. Try to post this on linked on Outsystems group as a post.

thanks suraj.

What are Templates?

Templates are modules and specific naming that become available is starting point when create new application .

Good efforts vijay   

Unique Key, Primary Key & Foreign Key

Primary Key

• Primary key cannot have a NULL value.
• Each table can have only one primary key.
• By default, Primary key is clustered index and data in the database table is physically organized in the sequence of clustered index.
• Primary key can be related with another table's as a Foreign Key.
• We can generated ID automatically with the help of Auto Increment field. Primary key supports Auto Increment value.

Unique Key

• Unique Constraint may have a NULL value.
• Each table can have more than one Unique Constraint.
• By default, Unique key is a unique non-clustered index.
• Unique Constraint can not be related with another table's as a Foreign Key.
• Unique Constraint doesn't supports Auto Increment value.

Foreign Key

• Foreign key is a field in the table that is primary key in another table.
• Foreign key can accept multiple null value.
• Foreign key do not automatically create an index, clustered or non-clustered. You can manually create an index on foreign key.
• We can have more than one foreign key in a table.
• There are actual advantages to having a foreign key be supported with a clustered index, but you get only one per table. What's the advantage? If you are selecting the parent plus all child records, you want the child records next to each other. This is easy to accomplish using a clustered index.
• Having a null foreign key is usually a bad idea. In the example below, the record in [dbo].[child] is what would be referred to as an "orphan record". Think long and hard before doing this.

 good job Vijay...

Really Appreciate #VijayMalviya

Just a note to the readers who may be reading the topic: the links from the first post link to the product versions and documentation pages that reached end of life and are no longer supported.

For an up to date documentation overview please check this link.

Greate work Vijay.. helpful. 

Very useful info .. thanks 

good work

Thank you for this summary was very helpful =)

It's really helpful....
Thanks Vijay.. 

Hi,

I was trying to find an answer to a question related to Agile but in different documentations, I got some different answers, Could you help me to answer it according to What Outsystems follows?

Q. What is the best time to write the test cases for an agile iteration?

Is it in parallel of development or after done with the development of the iteration or when?

Thanks

Nice summary about each and every topic..

Hello,

Helpful information at one place

Thankyou
Ayush Khare

Screen and Block Lifecycle Events

On Initialize

The On Initialize event handler executes after checking the permission of the user to access the Screen, but before navigating to the Screen and starting to fetch data.

In Blocks, including any server action calls or local storage operations in this flow might cause the render of the Block to start before this action finishes. You will have issues if you set any variables in this flow that affect the render.

Notes:

Keep this event handler action simple and avoid slow actions such as local storage operations, since it may delay the rendering of the Screen or Block.

Avoid accessing the data of the Screen or Block since this action runs before the data is fetched.

Use cases you can implement with this event handler:

Assign a variable based on inputs.

Assign a variable based on some computation in JavaScript, such as a random number.

Redirect the application to another Screen if the user doesn’t have the authorization to see the Screen (only possible if the event handler belongs to a Screen).

Assign the parameters of a child Block based on the inputs of the Screen.

Access variables of the JavaScript window object.

On Ready

The On Ready event handler runs when the Screen or Block is ready, i.e. when the DOM is ready, after the first render. In Blocks, this event happens before the same event of the parent Screen or Block. To ensure a fast and smooth Screen or Block render, this event is triggered even before the transition to the Screen ends.

Notes:

The DOM of the previous and current Screens are loaded when this event is triggered. To ensure that you are operating on the screen being created, execute logic only for the HTML div element with the class active-screen.

Keep this event handler action simple and avoid using Screen Aggregates or Data Actions, which run in parallel, to manipulate data that might not be available.

Avoid accessing the data of the Screen or Block since this action runs before the data is fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.

Use cases you can implement with this event handler:

Initialize a third-party component that needs the DOM.

Add listeners to a DOM element.

Set the focus on an input widget.

Add listeners to the JavaScript window object.

On Render

The On Render event handler runs after each time the Screen or Block is rendered, i.e. whenever the Screen or Block is opened (right after the On Ready event handler execution) and after any change of the data of the Screen. In Blocks, this event happens before the same event of the parent Screen or Block. You can use this event handler to update a third-party component such as a progress bar.

Notes:

Avoid changing Screen or Block data since every time this data changes the On Render event is triggered again and the app might run in an infinite loop.

Keep this event handler action simple and avoid slow actions such as server requests, since it may delay the render of the Screen or Block.

On the first render of the Screen or Block avoid accessing the data of the Screen or Block since there is no guarantee that the data is already fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.

Use cases you can implement with this event handler:

Act upon a change in the data of the Screen or Block to update a third-party component.

The same use cases as for the On Ready event handler.

On After Fetch

The On After Fetch event handler executes right after an Aggregate or Data Action finishes fetching data. Since each Aggregate or Data Action has its own On After Fetch event handler, you can implement logic to act upon the data retrieved from that data source.

Notes:

When the On After Fetch event handler runs, the data has arrived and is available but it isn't bound to widgets. This means that the widgets haven't updated yet.

Use cases you can implement with this event handler:

Assign the first or last record returned by the query to a variable.

In the master-detail pattern, to iterate a query to populate a list of lists.

For queries dependent on other queries, you can use this event handler to trigger the dependent Aggregate.

Use cases you shouldn't implement with this event handler:

Don't use the GetUserId() function at this moment to know the user that is currently authenticated. The parallel execution of Data Actions and client-side Agreggates in a Screen overrides the session authentication cookie. Therefore, using the GetUserId() function in the On After Fetch event might return an empty value.

On Parameters Changed

The On Parameters Changed is an event handler only for Blocks that runs after the parent Screen or Block changes an input of the Block. In case you have a Block inside another Block and a change of an input of the outside Block affects an input of the nested Block, the On Parameters Changed event handler of the outer Block runs b

Outsystem Delete Rules

When you create relationships between the Entities in your module, you must define which kind of referential integrity you want to use when deleting records. The referential integrity specifies what happens to a record of an Entity B that references a record of Entity A, when the Entity A record is deleted.

The following Entity Diagram defines the relationship between Customers (main Entity A) and Orders (related Entity B), where a Customer can have several Orders, and an Order belongs to one and only one Customer. The reference attribute, which corresponds in database terminology to a foreign key, is the attribute CustomerId in Entity Order.

In this example, specifying the referential integrity is to define what happens to the Orders of a Customer when that Customer is deleted.

To specify the referential integrity in a relationship between two Entities, you need to edit the reference attribute of the related Entity and set the Delete Rule property to one of the following values: Protect, Delete or Ignore.

Protect

Setting the Delete Rule to Protect prevents deleting records of the main Entity while there are associated records in the related Entity.

This behavior is ensured by a database constraint created on the reference attribute. If you try to delete a record in the main Entity that still has associated records in the related Entity, the Platform Server returns a database exception and the operation is not executed.

Delete

Setting the Delete Rule to Delete guarantees that when a record of the main Entity is deleted, all the associated records in the related Entities are also deleted. This mechanism is commonly known as Cascade Delete.

This behavior is ensured by a database constraint created on the reference attribute.

Ignore

Setting the Delete Rule to Ignore allows deleting records of the main Entity keeping the associated records in the related Entity.

The Ignore value does not guarantee referential integrity and, therefore, no database constraint is created. Accordingly, when you change the Delete Rule property from a previous value to Ignore, the corresponding automatic index is deleted (unless you have manually changed any of its properties).

If the foreign key attribute references an external Entity exposed by an Extension, the only possible value for the Delete Rule property is Ignore, as the referential integrity can’t be guaranteed.

When designing your Entities model, you must identify the correct Delete Rule for the several relationships, ensuring your system behaves as expected in each use case. Check below some examples and considerations for each option to help you choose the appropriate choice for your use case.

"Protect" Example

The Protect value is commonly used when the end user is able to delete the Entity data directly from the application’s screens.

Consider the following business scenario:

• There is an application screen where the end users can delete Customers.

• A Customer can have one or more Orders, and an Order belongs to one and only one Customer.

• A Customer cannot be deleted while there are associated Orders.

Setting the Delete Rule property of the reference attribute CustomerId to Protect assures that the end user won’t delete a Customer that still has associated Orders.

Trying to delete a Customer that still has associated Orders results in a database exception, and the operation is not executed:

In this case, to delete a Customer you must first delete all the Orders placed by that Customer.

This is the more performant option because you can control and optimize the individual delete statements, and still ensures data consistency. It’s a trade between having more control and performance, over higher implementation costs.

Advantages

• The data model is always consistent, as you won’t be able to delete a record of the main Entity that is still being referenced in the related Entities.

Constraints

• You must orchestrate the correct delete order in your logic, by deleting the records of the related Entities first, and then the record of the main Entity.

• Whenever you add a new related Entity to your model, you must include that related Entity in your delete cycle logic.

"Delete" Example

The Delete value is commonly used when you implement data purging mechanisms, where you need automatic cascade delete between the whole model.

Since data purging mechanisms are typically handled by an asynchronous process (Timer or BPT), performance is not a concern.

Consider the following business scenario:

• We want to delete all the closed Orders older than five years.

• An Order has one or more OrderItems, and an OrderItem belongs to one and only one Order.

• When an Order is deleted, all the associated OrderItems must be deleted.

Setting the Delete Rule property of the reference attribute OrderId to Delete assures that when an Order is deleted, all the related OrderItems are also automatically deleted.

Advantages

• The data model is always consistent. When you delete a record of the main Entity, that record won’t be referenced in the related Entities anymore, as all the associated records in the related Entities are also deleted.

• The development and maintenance of your delete logic are straightforward, as you only need to delete the records at the main Entity level.

• Adding new related Entities to your model implies low development effort, as you only need to set the Delete Rule of the reference attributes to Delete.

Constraints

• Depending on the number of related records, this option can lead to poor performance. For every delete operation, the related Entities will be checked for related records, causing the delete statement to take longer. Therefore, this option is not recommended when you have a complex Entity model and performance is a concern (for example, the end user is able to delete the Entity data directly from the application’s screens).

"Ignore" Example

The Ignore value is commonly used when you implement historical data archiving mechanisms, where you want to delete records from the main Entity but you need to keep all the records in the related Entities, considering that the details of the main record are not relevant.

Consider the following business scenario:

• Every operation performed over an Order is logged in OrderHistory.

• One OrderHistory record relates to one and only one Order and one Order has one or more related OrderHistory records.

• We want to delete all the closed Orders older than five years, but the OrderHistory records must be kept for 10 years, for compliance reasons.

Setting the Delete Rule property of the reference attribute OrderId to Ignore allows you to delete an Order and keep the related OrderHistory records.

Advantages

• You can delete records in the main Entity without impacting the related Entities.

Constraints

• This option leads to an inconsistent data model. It keeps the related records, but you can no longer fetch the details of the main record, only the identifier.

• When you change the Delete Rule property of a reference attribute from a previous value to Ignore, the corresponding automatic index is deleted. In case you use that reference attribute as a query filter, you need to manually add a new index.

Wow great efforts Vijay!! 

Reactive Web Lifecycle Events

EventDescription

On Initialize

The On Initialize event handler executes after checking the permission of the user to access the Screen, but before navigating to the Screen and starting to fetch data.

In Blocks, including any server action calls or local storage operations in this flow might cause the render of the Block to start before this action finishes. You will have issues if you set any variables in this flow that affect the render.

Notes:

• Keep this event handler action simple and avoid slow actions such as local storage operations, since it may delay the rendering of the Screen or Block.
• Avoid accessing the data of the Screen or Block since this action runs before the data is fetched.

Use cases you can implement with this event handler:

• Assign a variable based on inputs.
• Assign a variable based on some computation in JavaScript, such as a random number.
• Redirect the application to another Screen if the user doesn’t have the authorization to see the Screen (only possible if the event handler belongs to a Screen).
• Assign the parameters of a child Block based on the inputs of the Screen.
• Access variables of the JavaScript window object.

On Ready

The On Ready event handler runs when the Screen or Block is ready, i.e. when the DOM is ready, after the first render. In Blocks, this event happens before the same event of the parent Screen or Block. To ensure a fast and smooth Screen or Block render, this event is triggered even before the transition to the Screen ends.

Notes:

• The DOM of the previous and current Screens are loaded when this event is triggered. To ensure that you are operating on the screen being created, execute logic only for the HTML div element with the class active-screen.
• Keep this event handler action simple and avoid using Screen Aggregates or Data Actions, which run in parallel, to manipulate data that might not be available.
• Avoid accessing the data of the Screen or Block since this action runs before the data is fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.

Use cases you can implement with this event handler:

• Initialize a third-party component that needs the DOM.
• Add listeners to a DOM element.
• Set the focus on an input widget.
• Add listeners to the JavaScript window object.

On Render

The On Render event handler runs after each time the Screen or Block is rendered, i.e. whenever the Screen or Block is opened (right after the On Ready event handler execution) and after any change of the data of the Screen. In Blocks, this event happens before the same event of the parent Screen or Block. You can use this event handler to update a third-party component such as a progress bar.

Notes:

• Avoid changing Screen or Block data since every time this data changes the On Render event is triggered again and the app might run in an infinite loop.
• Keep this event handler action simple and avoid slow actions such as server requests, since it may delay the render of the Screen or Block.
• On the first render of the Screen or Block avoid accessing the data of the Screen or Block since there is no guarantee that the data is already fetched. If you need to develop some logic on these data, use the On After Fetch event handler of the respective Aggregate or Data Action.

Use cases you can implement with this event handler:

• Act upon a change in the data of the Screen or Block to update a third-party component.
• The same use cases as for the On Ready event handler.

On After Fetch

The On After Fetch event handler executes right after an Aggregate or Data Action finishes fetching data. Since each Aggregate or Data Action has its own On After Fetch event handler, you can implement logic to act upon the data retrieved from that data source.

Notes:

• When the On After Fetch event handler runs, the data has arrived and is available but it isn't bound to widgets. This means that the widgets haven't updated yet.

Use cases you can implement with this event handler:

• Assign the first or last record returned by the query to a variable.
• In the master-detail pattern, to iterate a query to populate a list of lists.
• For queries dependent on other queries, you can use this event handler to trigger the dependent Aggregate.

Use cases you shouldn't implement with this event handler:

• Don't use the GetUserId() function at this moment to know the user that is currently authenticated. The parallel execution of Data Actions and client-side Agreggates in a Screen overrides the session authentication cookie. Therefore, using the GetUserId() function in the On After Fetch event might return an empty value.

On Parameters Changed

The On Parameters Changed is an event handler only for Blocks that runs after the parent Screen or Block changes an input of the Block. In case you have a Block inside another Block and a change of an input of the outside Block affects an input of the nested Block, the On Parameters Changed event handler of the outer Block runs before the same event of the nested Block. You can use this event handler to adapt the Block to the input parameter changes, such as to update variables or rerun Aggregates and Data Actions.

Use cases you can implement with this event handler:

• Refresh an Aggregate or Data Action that depends on that input parameter.
• Recalculate a variable that depends on the input parameter.

On Destroy

The On Destroy event handler executes when the Screen or Block is going to be destroyed. In Screens, this event happens when the transition to the new Screen ends. In Blocks, this event happens before the Block is removed from the DOM. This event is triggered following a top-down order: in case you have a Screen with nested Blocks, the event first happens in the Screen, then in the outer Block, and afterwards in the nested Blocks. You can use this event handler to implement logic to remove any footprint of the Screen or Block such as removing event listeners.

Notes:

• The DOM of the present and target screens is loaded when this event is triggered. To ensure that you are operating on the screen being destroyed, execute logic only for the HTML div element with the class active-screen.
• Keep this event handler action simple and avoid slow actions such as server requests, since it may delay the removal of the Screen or Block and, in the case of exiting a screen, the loading of the next screen.

Use cases you can implement with this event handler:

• Call the destroy action of third-party components.
• Clean the DOM to run a plugin again.
• Remove JavaScript listeners.

Thanks.. Very informative.

Great job..

Very helpful information.Thanks all !!!

Differences to consider between Traditional and Reactive Web Apps

This document presents some differences between the Traditional Web and Reactive Web Apps, in the context of migrating to the newer Reactive runtime. Refer to your Traditional apps and check how you implemented user experience and logic related to these new features, and assess what you need to change in the new runtime.

Traditional Web App elements not available for Reactive Web Apps

These are the elements commonly used in the Traditional Web that aren't available for Reactive Web Apps. These documents also provide some helpful tips on how you can get similar functionality in the new app.

Ajax Refresh

Ajax Refresh in Traditional Web Apps refreshes parts of the interface. The UI elements in Reactive App refresh automatically on data change, so you don't need to use Ajax Refresh.

Entry

The Entry node in Traditional Web Apps defines the default page that loads in the UI Flow. It points to the index Screen of the flow.

Notify

Notify and NotifyGetMessage enable Widgets in the Traditional Web to exchange data, and they're not available in Reactive Web.

In Reactive Web Apps, use Events and corresponding handler Actions. Check how to do that in Use Events to Propagate Changes From a Block to the Parent.

Exception handler

You can catch exceptions on both the client and server side.

Preparation

Preparation, a dedicated server-side Action that loads initial data for Screens, doesn't exist in the client-side Reactive interface. The absence of the Preparation Action is an important difference between Traditional Web Apps and Reactive Web Apps. You need to recreate the data fetched on the client side.

Session Variable

Session Variables are a server-side feature of Traditional Web Apps to store session information that you can access across the app. In Reactive Web Apps, store information in Client Variables, which you can initialize the On Application Ready System Event.

For details on how to migrate this element to Reactive, check the notes on migration Session Variables.

Date Time in Reactive

Reactive Web Apps treat date and time values like Mobile Apps. The Date and Time values are always UTC, even when requested from the server. When you use them in the app UI, there's a value conversion to the local time of the device. Improved practices in Reactive

This section provides general notes about the changes in how you approach development in the Reactive Web Apps when compared to Traditional Apps.

More Client Actions, less custom JavaScript

The focus of Reactive Apps is the Front-end, driven by the client-side logic. This should enable you to use less custom JavaScript, replacing it with Client Actions. Use Client Actions instead of custom JavaScript code whenever possible.

Optimize data fetching on the client side

Design how Aggregates of a Reactive Web App should fetch data, by setting Aggregate Fetch property to At Start or Only On Demand. This provides a lot of flexibility for designing UI Patterns and speeds up the responsiveness of the UI.

Use Libraries for solid architecture

You can use Libraries to optimize the number of dependencies in the environment where the apps are running. You can also convert an existing Mobile or Reactive Module to a Library.

Use client-side validation for quick feedback about values

Reactive Web Apps provides an efficient way to validate data on the client side. There's an example in Validate Form Inputs. The client-side validation is there for a quick feedback to your users about the values they're submitting. However, you should implement your server-side validation to make sure that the correct data gets saved in the database.

useful