Webscreen=Public vs ExternalURL

Webscreen=Public vs ExternalURL

If you like to use an outsystems webscreen that is located in another eSpace, which is the preferred 

1) Set the provider webscreen to public then consume it or 
2) Use a external URL and redirect it to the assocated URL page.

-You can use either option 1 or 2 if the application page is an outsystems eSpace webscreen 
(why would you use option 1?)
-You can use option 2 if the application page is an external (ie not an outsystems eSpace webscreen).

Hi Robert,

In fact any of the implementations that you mentioned are valid, but there is a huge difference between the two from a application management perspective.

1) In option 1 you have an "early-binding" like reference, where it is specified in the application model in development time that your Consumer application depends on the PublicWebScreen of your Producer application. The benefits are the following:
  • This dependency is explicit in Service Studio and ServiceCenter
  • The usage of this screen will be clearly visible in Service Studio flows (explicit in the application model)
  • The usage of this reference will be always validated (for example, if you pass the wrong parameters, you will see an error)
  • The consistency of the dependency will be validated whenever you publish your Consumer eSpace - if for some reason the PublicWebScreen interface becomes incompatible with the Consumer eSpace (imagine a parameter is removed) you will immediately be warned and will be able to fix the situation before it hits your users;
2) In option two you have a "late-binding" like reference. What happens is that you compute a URL string in runtime. Even though your Consumer application in fact depends on the PublicWebScreen of your Producer application, this is not explicit in the application model. This means that, if this reference becomes invalid, you will only see it when the user gets an error screen. The benefit of this option is that, when you change the producer, this will immediately affect your consumers. The consequence is that you will be only able to detect errors in runtime, the dependency will be harder to use and understand and whenever you have problems you will have a much harder time debugging the situation .

Now, imagine a world with hundreds of references between eSpaces. What would you prefer? To have them invisible and generating errors in runtime, or having them explicit, visible and constantly being validated for consistency in your model?

In fact, this ability to explicitly define and constantly validate references in the application model is one of the most important strengths of the OutSystems technology. This is what we call the TrueChange engine - your applications are constantly being validated for internal and external consistency. Whenever you make a change, the impact of that change in the remaining layers of the application is evaluated. Additionaly, whener you publish an application to your server, all the external dependencies are validated for consistency also.

I leave you some screenshots to support what I just said.

Best Regards,

Daniel Lourenço
Daniel ,

Great answer, so the best option is to use option #1 where possible,

makes sense.