139
Views
10
Comments
Improved support for enumerates in Consumed SOAP Web Services
Hi all!

When using the Platform to Consume SOAP Web Services some of the types defined in the service are represented in the Platform as a correspondent Data Type.

Up until now, one of these conversions was that Enumerate values defined in the service would be represented by the Text Data Type, losing all type safety and easy development that is associated with Enumerations.

This made it really hard for developers to fill the inputs and attributes with the Enumerate values, since they needed to go read the external services documentation in order to know what were the possible values.
This process was also error prone and there were no TrueChange™ validations as is common in the Platform.


 

Not anymore!

As of 8.0.1.31 and 9.0.0.23 there is a new feature that implements the WSDL enumerated types idea.
So, from now on Enumerates from SOAP Web Services are imported as Static Entities.

This allows a fully typified and TrueChange™ aware usages!



 



What do I need to use this improvement?
To be able to use this it is required both the development environment and Platform Server be at or above the 8.0.1.31 and 9.0.0.23 versions (for Platform 8 and Platform 9, respectively).


I already have existing SOAP Web Services that still have Text Data Types! What do I need to do?
This change causes old Text usages to become invalid, therefore there is no automatic upgrade. If you have existing services that you want to convert to the model, there is a new Refresh option available. Choosing this Referesh option will cause the Enumerate values that were previously imported as Text to become Identifiers. So, you will need to check the TrueChange™ tab for errors and replace your existing strings for the correct expressions.



What if I want to keep using the Text Data Types when consuming new services?
Since there is no advantage of using the Text Data Type we are only keeping the existing ones for compatibility purposes. You can use older versions of Service Studio to consume them, but the new model is highly recommended.


Regards,
João Rosado
2016-04-21 20-09-55
J.
 
MVP
kudos!
2015-01-16 15-29-02
Brynjar Magnússon
Are the Static Entities created this way counted as application objects?
2012-03-16 12-21-09
João Rosado
Staff
Hi Brynjar,

These static entities are just like any other (not read-only like the rest of the web reference structures) and can be used normally, so they do count application objects.

Regards,
João Rosado
2025-11-03 12-56-18
Evert van der Zalm
 
MVP

Great to read!
2020-07-08 08-24-35
João Costa
Hello there,

I tried to consume a WS but the new option isn't shown.

Using version 9.1.0.20 on personal environment.

Did I miss any config or is this a bug?

Cheers,

João




Refresh SOAP Web Service (importing enums) - not available
2012-03-16 12-21-09
João Rosado
Staff
Hi João

The option there is only to upgrade old web references to the new model.
Any newly Consumed Web Services will automatically get it if there are enumerates described in the service wsdl.

I just tested it in my personal and worked fine.

Edit: just noticed the names on your example are the default for Outsystems Exposed Web Services. This improvement is only to consume external services. The ones generated by the platform do not (yet) define enumerates in the service description, so are not able to take advantage of this.

Regards,
João Rosado
2019-01-31 07-44-24
Mohamed Berayek (Break)

Assume WSDL1 have an enumeration in the namespace {XYZ.MyEnum}

and WSDL2 have the same enumeration in the same namespace.


Now, parsing the 2 WSDL files, outsystems create 2 Static Entity with names MyEnum and MyEnum2


Which is a bit strange since they are the same enumeration in the same namespace in the 2 wsdl files.

2012-03-16 12-21-09
João Rosado
Staff

Hi Mohamed,


True, its a bit strange. But it follows the same logic as the structures. Each web reference has it's own structures below it, instead of being defined at the module level. This ensures that each imported service is self contained.

Due to current architecture limitations we could not place Entities below the correspondent Web Reference, but in the future we would like to upgrade them to be just like the structures keeping each web reference self contained. That is way the current implementation already presents the limitation it should have in the future.


Regards,
João Rosado

2019-01-31 07-44-24
Mohamed Berayek (Break)

João Rosado wrote:

Hi Mohamed,


True, its a bit strange. But it follows the same logic as the structures. Each web reference has it's own structures below it, instead of being defined at the module level. This ensures that each imported service is self contained.

Due to current architecture limitations we could not place Entities below the correspondent Web Reference, but in the future we would like to upgrade them to be just like the structures keeping each web reference self contained. That is way the current implementation already presents the limitation it should have in the future.


Regards,
João Rosado

Thank you João,

however, since the 2 enumeration are on the same namespace within both WSDL files, can't this be used to identify that they are actually a single entity/enumeration?


2019-07-08 11-04-35
Leonardo Fernandes
 
MVP

Mohamed Berayek wrote:

João Rosado wrote:

Hi Mohamed,


True, its a bit strange. But it follows the same logic as the structures. Each web reference has it's own structures below it, instead of being defined at the module level. This ensures that each imported service is self contained.

Due to current architecture limitations we could not place Entities below the correspondent Web Reference, but in the future we would like to upgrade them to be just like the structures keeping each web reference self contained. That is way the current implementation already presents the limitation it should have in the future.


Regards,
João Rosado

Thank you João,

however, since the 2 enumeration are on the same namespace within both WSDL files, can't this be used to identify that they are actually a single entity/enumeration?



It's not that straightforward. You could be integrating with two different versions of the same WSDL, so they would have the same namespaces but the enum values could be different.

Another issue arises with refreshing. What would happen if there's a single static entity, shared by both services, but then you decide to refresh just one of the services? If the refresh needs to update the static entity, it would affect both services, even though you are only refreshing one of them.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.