Software Units vs Application Objects

  
Hi,

Since OutSystems will replace Software Units by Application Objects, the sizing tool will be updated to return the expected number of Application Objects?
Or, perhaps, there is one easy way to translate Software Units to Application Objects?

Thanks,
Hélder Anselmo
Hi,

To my knowledge, there is no tool available yet to convert SUs into AOs. Depending on your license (old or new), you should be able to see the relevant number in service center.

FYI, this is the description I got to what is counted as an AO.

1. Pages - the screens you design for the end users to use. It includes web screens, email screens, mobile web screens, sms screens as designed in the visual development environment
o    E.g.
  A Supplier_List web screen = 1 Application Object
  A pop-up web screen = 1 Application Object
 
2. Tables - Entities that you design in the Platform, or tables in external databases that you integrate with (import via Integration Studio)
 
3. API / Service operations - methods from web services or REST that you consume or expose.
o    Examples:
  Consuming Google Calendar APIs
·         Each method defined there that you import to the platform is 1 API
·         Each will be 1 application object.
  3 SAP BAPIs consumed via a WebReference -
·         GetCustomers, CreatePurchaseOrder, GetCustomersPOs
·         = 3 Application Objects
  CustomerInformation webservice with 4 actions
·         SearchCustomers, GetCustomerDetail, CreateCustomer, UpdateCustomerDetail = 4 web service methods exposed to a third party system
·         = 4 Application Objects
  A REST web reference  with 14 methods = 14 Application Objects
 
APIs in extensions (Java or C# code that you reuse in the platform) are not accounted for.
Web services are APIs (internal or external). References are not.
Hélder and Kurt-
 
For clarification and discussion regarding commercials/process/tools, please get in touch with your OutSystems partner manager directly. We want to ensure that specific approach and timing are properly discussed so as to not create confusion in your market.

Given the difference in calculation, there is no reliable direct conversion from SU to AO. With the simplicity of AOs, it should be relatively simple to estimate capacity requirements.
 
Best regards-
Sean
 
Hi,

Just to expand on Kurt's previous responce, can I please have clarification on the following allocation of Application Objects:

Pages
Web Screens 1 AO
Email Screens 1 AO
Mobile Web Screens 1 AO
SMS Screens 1 AO
Web Blocks 0 AO
 
Tables
Entities (Single and Multi-Tenant) 1 AO
Static Entities 1 AO
External Tables (Via Integration Studio) 1 AO
Structures 0 AO
Reference Entity from external Outsystems Espace 0 AO

API Methods
Consume Third Party REST API / Web Reference 1 AO
Expose Outsystems REST API / Web Service 1 AO
Consume API from Integration Studio Extension 0 AO
Consume Action from external Outsystems Espace 0 AO
 
Additional
Site Properties 0 AO
Session Variables 0 AO
Timers 0 AO
Process 0 AO
Roles  0 AO
Themes 0 AO
Placeholders 0 AO


Please feel free to include anything that I may have left out.

Thanks,
Robbie
If I have a license of 150.000 or 300.000 software units, how many Application Objects will I get with v9?

There is not much info about this...
Will we get some documentation about this in the near future?

Hi Carlos, for clarification and discussion regarding commercials/process/tools, you can get in touch with your OutSystems partner manager directly, in this case me :-) I will call you to clarify this doubt with all related commercial context. Thanks.
It would be nice to have a idea about what is expensive in AO to know how you should design your apps to minimize AO use .. for instance if an espace is expensive a architectural model having a lot of eSpaces wouldn't be a good solution. 

Robbie Nati wrote:

Hi,

Just to expand on Kurt's previous responce, can I please have clarification on the following allocation of Application Objects:

Pages
Web Screens 1 AO
Email Screens 1 AO
Mobile Web Screens 1 AO
SMS Screens 1 AO
Web Blocks 0 AO
 
Tables
Entities (Single and Multi-Tenant) 1 AO
Static Entities 1 AO
External Tables (Via Integration Studio) 1 AO
Structures 0 AO
Reference Entity from external Outsystems Espace 0 AO

API Methods
Consume Third Party REST API / Web Reference 1 AO
Expose Outsystems REST API / Web Service 1 AO
Consume API from Integration Studio Extension 0 AO
Consume Action from external Outsystems Espace 0 AO
 
Additional
Site Properties 0 AO
Session Variables 0 AO
Timers 0 AO
Process 0 AO
Roles  0 AO
Themes 0 AO
Placeholders 0 AO


Please feel free to include anything that I may have left out.

Thanks,
Robbie


Why email screen need to be charge as one AO...? 

In that case, i would rather create an "Email setup page" with "Subject", "Content", "Receiver". Then fetch the respective email content and construct the email on the fly. With such design, i will save a lot if i have 50 different email template :D

True, but the objective of both SU and AO is to account for the advantages you get by using the platform features.

You can work around not using them, but in long term it affects developer productivity, learning security and maintenance of your application.

João Rosado wrote:

True, but the objective of both SU and AO is to account for the advantages you get by using the platform features.

You can work around not using them, but in long term it affects developer productivity, learning security and maintenance of your application.

I think the same way, but I am disappointed when I realized the email can't attach pie chart