Assocation direction and web services

2
Mendix issue: Mendix version 4.2.2 Does anyone knows if the direction of the original association should have an impact on the way the association is shown in a Mendix generated WSDL? Example, I have two entities a) MainEntity and b) SecondEntity, I have created b to store a subset of data (person information for instance) from entity a, entity a is storing ticket information in my case. When I create the association between a and b I start from b and go to a, by default b references to a, since I don't want this, I changed the association to be referenced on both sides (one on one relation). When I generate the WSDL two containers are generated in which the association is stored (not really usefull now since it's a one to one relation), the top container has maxOccurs 1, the second container is unbounded however, I've tested this and the web server allows posting with multiple repeats, the relation is however only created with the last item in the repeated structure. Now when the relation is created the other way around, so from a to b, the second container is no longer unbounded and now has maxOccurs 1, is there a valid reason for this behaviour? The excerpt below is generated from an example project with two entities, a MainEntity and a SecondEntity, there are two associations between the entities, note the names for the direction in which they where originally created. <xsd:element name="MainEntity"> <xsd:complexType> <xsd:sequence> <xsd:element name="Attribute" type="xsd:string" minOccurs="1"/> <xsd:element name="SecondEntity_MainEntity" minOccurs="0" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="SecondEntity" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Attribute" type="xsd:string" minOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="MainEntity_SecondEntity" minOccurs="0" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="SecondEntity" minOccurs="0" maxOccurs="1"> <xsd:complexType> <xsd:sequence> <xsd:element name="Attribute" type="xsd:string" minOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>
asked
1 answers
3

Ivo, before you worry about the webservice, you need to make sure you have set up your domain model and associations correctly to store your data.

Having a one-to-one relationship between your 2 entities means that a contact can only ever be linked to a single ticket, and a ticket can only ever be liniked to a single contact. If you create a new ticket record and link it to the contact, this will replace any existing link from that contact to a previous ticket. I assume this is not what you want.

Normally you would want to allow a single contact record to be linked to multiple tickets. To do this you need to create the relationship by dragging from the ticket entity to the contact entity (Ticket_Contact, a_b) which I think is the opposite direction to the one you have created.

Edit after comments:

I'm having a problem understanding your requirements. Question, so there are additional attributes that are not part of the ticket or the contact, but part of the link between the two? If so, you need to change your domain model to create an intermediate entity to store this data. This entity would need a one-to-many association to both the ticket and the contact and would replace the direct association between the two

Edit after diagram:

That's a bit clearer. So you have 'temporary' entities published as a webservice. There is no reason why you need 2 entities - you could have a single one that contains parameters that will be used to capture the data needed to create the ticket and validate/link to the contact. You could even have no temporary entities at all...

Remember, a wsdl in Mendix is actually a microflow that you publish, with input parameters, then whatever actions you wish.

Say for simplicity you need the loginname of the contact to be able to identify them, and you need the Summary, Description and Urgency of the ticket to create (you will probably need more than these 4 parameters, but let's keep it simple).

Create a microflow with 4 parameters corresponding to these attributes. In the microflow, use the loginname parameter to retrieve the Contact record. If it can't be found exit the microflow; if found create the ticket using the other 3 parameters, and set the association between the new ticket and the retrived contact record. Get your microflow to return a success boolean or string, such as the identifier of the ticket created.

Then right-click the microflow and choose to Publish as web service operation. Make sure the permissions to create objects in your domain model are correct and that the wsdl user has sufficient rights. You can add any validation to the data you need in your microflow.

All this can be achieved without having a 'staging' entity/ies.

Alternatively, your microflow could simply create a record in a temprary staging entity, and you could then process it later and clean up the old data using a scheduled event. This might give better performance of the wsdl if not having the ticket created immediately is acceptable.

answered