This is not so much a question, but a collection of issues with consuming and publishing webservices I've ran into using Mendix up to version 4.5.2. For almost all of these issues I've got tickets that are back logged, but haven't been picked up so far. It might be an idea to vote for this question and hope Mendix is going to pick this up. Of course if other people have other issues with consuming are publishing web services (would be nice if these are acknowledged by Mendix to be either bugs or feature requests), feel free to add to this article. Issue #1 is actually a bunch of issues which are related to validation of webservices that are published by Mendix: Issue 16983 (Nominated for release) I'm having problems getting Mendix to check mandatory fields in a web service. I've created a very simple web service, it contains three string fields that are marked in the published web service as non optional. When I check the WSDL I can see that minOccurs=1 for all three attributes. I would expect the web server to do something when one of these fields is empty, but no matter what I try, this doesn't happen. The web service is more than happy to except messages that have empty mandatory fields and fields that do not even exist. Also, when I expose a one to one relation in a web service, Mendix shows in the WSDL that minOccurs = 0 and maxOccurs = 1, when I sent a message with more repeats is not a problem at all, Mendix will only fill the relation of the last item in the repeating structure and orphans the rest. Am I missing something here? I would expect some form of validation?! Actual behavior No validation is taking place at all, all answers to my forum post suggested this should be working but is not. A test project has been added to the ticket. Expected behavior Validation should take place, when mandatory field are missing or other things are done in an inbound message that do not comply with the Mendix generated WSDL the web service should prevent further processing and respond with an error (when possible not a java stack trace, but an error that is somewhat easier to read). The next issue is a feature request: Issue 11502 (Scheduled for backlog): I have a published webservice that uses an entity as its input parameter, the entity is a generalization of an entity that holds incoming message attributes that are common for all published webservices. I would like to have the fields that are inhereted from the generalization to appear first in the wsdl, they are however placed after the regular entity fields. I would like it to be possible to change the order in which fields appear in the WSDL, when the fields are inhereted. See forum: https://forum.mendix.com/questions/3426/WSDL%20attribute%20order%20with%20generalization Actual behavior It is not possible to change the order of the fields coming from the generalized entity in the WSDL. Expected behavior The ability to change the order of fields, regardless of generalization. Issue #3 Is a feature request of sorts, but could also be thought of as incomplete implementation of functionality in the first place and has to do with implemenation of self references in web services: Issue 15197 (Scheduled for backlog): When the parent in an one to many relation is exposed to the interface, the children are being put in a repeating structure in the webservice, when the repeating structure i s filled in an incoming message, the association to the parent on the children entries is automatically filled in. This is also shown in the exposed webservice, the relation shows up as a list of child entities. I however, have an entity with a one to many self reference that I want to expose to an interface, the entity is a ticket with its tasks. If I do this it seems that in the resulting webservice that is created, this relation can only be used in one way, it can only be used to store the parent of the current incoming ticket. This theory is supported when I look in the webservice, the relation is not showing up as both a list of entities (if you want to use the repeating structure to populate the children) and as a single entity (if you want to create a parent) but only as a single entity. This is however not what I want, I want the entries in the repeating task structure to become children of the ticket entry. For now I've managed to work around it by creating a many to many relation, the parent is in this case holding the associations to the children and it takes me some more work to retrieve the parent from a child, but at least it works. My question is: Is what I described above correct and is it indeed not possible at the moment to have a repeating structure in Mendix, that is associated with an one to many self reference and to fill the children from the repeating structure instead of the parent. the structure in the interface message would look like this: <Ticket> <Ticket attributes...></Ticket attributes...> <Tasks> <Task> <Task attributes...></Task attributes...> </Task> <Task> <Task attributes...></Task attributes...> </Task> </Tasks> </ticket> I've attached a picture to clarify. Issue #4 is an issue with boolean fields in published web services of Mendix, support claims it's a feature request, though it seems to me to be an incomplete implementation of the standard: Issue 19438 (Scheduled for backlog): Created a web service that accepts an attribute of type boolean. Actual behavior According to http://www.w3.org/TR/xmlschema-2/#boolean legal values for an attribute of data type boolean are: true false 0 1 Mendix however seems to accept only true or false (with freedom to use capital letter, so TRUE or FALSE or any combination is allowed as well). Expected behavior The web service should be able to accept true false 0 1 as values in a boolean type field in a web service Issue #5 I don't have a ticket for (yet, I'm going to do this asap) but boils down to this: Whenever an attempt is done to import a WSDL with complex types that are set to mixed (mixed="true") Mendix throws an error, the way around this is to manually change the WSDL. It would be nice if there is a way to have Mendix import these elements without manually editing the WSDL (and thus keeping it original).
Ivo de Boer
Thank you Ivo for sharing this information with us.
"Integration is made easy through a complete web services based architecture, and prebuilt
connectors and templates. Integration can either include traditional data transfer and synchronization
methods or much faster enterprise mash-ups which allow you to tap into data from other systems very
quickly and without the need to move data from one system to another."
So far I have never encountered a SOAP web service that was able to integrate in standard way. Always with a lot of work-around and time
No optional fields, required to have a field values (integer and Data time) and not support empty values, Rendering all other data type beside string to be useless.
Not able to control the name of the output(replay) of Mendix (your stuck with the domain names)
No support of the 'any' type
And many more. Probably Mendix must have a huge backlog on Web services. I wonder if Mendix is planning to extend their possibly to support more complex web services?
Or does Mendix sees SOAP as old fashioned, and is not willing to do more development to support this protocol?
Hi Ivo, thank you for your feedback. I am sorry that we haven't been able to provide a solution for your issues sooner but I assure you that we are aware of them.
SOAP has not been declared old fashioned yet. ;-)
Reinout van Schouwen
Ivo, we have picked up issue 16983. In one of the next releases of Mendix it will be fixed.
We understand that it can be frustrating to send improvement suggestions and bug reports and that some stay on the backlog for such a long time. But they are not lost!
We won't stop investing effort in integration (including web services/SOAP) as we know it is very important for the product and our users.