Quote from "Delivery Manager Course 1: Building It right"

"As a rule of thumb, extensions should be wrapped by eSpaces that will provide a more simple interface with external systems"

 

Please explain, the reason why it would be necessary for an extension to be wrapped by an eSpace before it can be consumed? 

 

Example: You have an extension that consumes 3rd party web service X

 

Your Application Z would like to connect to service X, you can just reference the extension X and simply consume it, without first wrapping it around another eSpace, as suggested in the training material. 

 

REF: http://www.outsystems.com/Training/Module.aspx?MaterialId=396&CourseId=3&ShowTest=False&SkillLevelVersionId=148&RoleId=155

Robert -

My guess is that it is written wrong. I suspect that what they meant was to wrap the extension in an eSpace, so that you could expose it TO external systems more easily (ie: put the functionality into an eSpace Action so you can easily make it into a Web service call).

J.Ja

As I see it it is probably related to the nature of the extension. If we're talking about simple exposure of .Net APIs for instance, there is (usually) no need to do that.
I don't have the course in the back of my mind but as far as I can remember, that is mentioned in the chapter that talks about architecture (Business Processes, Core Entities/Services, Connectors). And that rule of thumb is related to the extensions in the "connectors layer". These are the extensions that should be wrapped in an espace.The wrapper espace responsibilities should be

• Hide away complexity in maintaining sessions (ex: if you need to log in to SalesForce before each api request, that should be done in the wrapper espace)
• Handle auditing, logging and exception handling logic (ex: if you need to audit every SAP request, do it in the wrapper espace)
• Hide and standardize service API complexity (ex: if you connect to 3 different storage systems, make a common facade in the espace)
• Perform type-mapping (ex: external APIs usually exchange string codes and other low level parameters that are not strongly typed. The OutSystems applications provide you facilities like Static Entities that bring much more value to an enumerate or string code. Use static entities accross the application and use the wrapper espace to map between your app's internal types and the external system types)
• Increase maintanability (it is common that an API changes - suppose you add a parameter to an SAP BAPI - , but accross the application the old behavior should be kept. the wrapper espace should work out how to do that, via optional parameters, default values, specific backward compatibility logic, etc)

It will surely work if you use the extension directly... but you'll avoid future refactorings by doing this.
Gonçalo Borrêga

• Hide away complexity in maintaining sessions (ex: if you need to log in to SalesForce before each api request, that should be done in the wrapper espace) Agree
• Handle auditing, logging and exception handling logic (ex: if you need to audit every SAP request, do it in the wrapper espace) Agree
• Hide and standardize service API complexity (ex: if you connect to 3 different storage systems, make a common facade in the espace) Agree
• Perform type-mapping (ex: external APIs usually exchange string codes and other low level parameters that are not strongly typed. The OutSystems applications provide you facilities like Static Entities that bring much more value to an enumerate or string code. Use static entities accross the application and use the wrapper espace to map between your app's internal types and the external system types) Agree
• Increase maintanability (it is common that an API changes - suppose you add a parameter to an SAP BAPI - , but accross the application the old behavior should be kept. the wrapper espace should work out how to do that, via optional parameters, default values, specific backward compatibility logic, etc), A good design Public API is forever and should not change. Most enterprise understand this and usually will provide backward compatibility within their public API. 

It will surely work if you use the extension directly... but you'll avoid future refactorings by doing this. It would depend on the situation and solution to be provided, therefore sometimes its not recommended to wrap an extension around an eSpace. However if you are unsure what to do, the safest route but not always the best route is to wrap an extension around an eSpace, the best route to take is to really know what you are doing and decide on your own :)

Therefore the training material is correct, it takes the safest route, you cant go wrong if you follow the training material and wrap the extension around an eSpace, but you could go wrong if you dont do it! really depends.