AUTO COMMIT webservices spoiling upsert behaviour

1
Hi, I would like to have a bypass for the autocommit behavior of Mendix on incoming webservice calls. Anyone having a clue? Context I have exposed a microflow as webservice (via WSDL). The microflow accept an domain entity as input parameter. The intended behaviour of the microflow should be 'upsert'. Upsert means: the microflow takes the functional key of the parameter and queries the database with it if the object is found, it will be updated with the attributes of the parameter if the object is not found, the parameter will be inserted as a new object. Before the object should be committed, quite some rules should be checked by the microflow. The problem Mendix is committing the input parameter at the moment you call the webservice. This raises two problems: The data is stored in the database before it has been checked by the microflow rules The parameter will allways be inserted as a new object Allready rejected solutions Implementing the rules as 'before commit event' on the domain model is not possible due to all kinds of other problems arising by doing so Creating another special entity with the same attributes as the original object is possible, but creating ton's of work because we have lots of webservice method calls, quite some domain entities each with a lot of attributes (I am not work-shy, but there are limits....) SOLUTION POSSIBLE ? ? An elegant way should be that the parameter is consumed by the microflow WITHOUT committing it by default en let the microflow do the commit..... Does anyone know if this is possible??
asked
3 answers
6

You could create an "integration" version of the entity that is non-persistent. Once it passes the validations you could create and commit the object you want it to become.

answered
2

It seems I found an solution together with Bert Koot (thanks pal!).

The steps are:

  1. Create lists of objects you would like to commit
  2. Iterate over the datastructure you received from the webservice.

  3. Retrieve for each webservice object the object from the database by using the technical/functional key.

    a. If found: use CommunityCommons.Clone to overwrite all the attributes from the webservice object to the business domain object

    b. If not found: create a new object and use CommunityCommons.Clone to fill it

    c. Add the created or updated object to the the list 'toCommit'

  4. Do all business rule checks on the objects in the 'toCommit' lists.

  5. Call CommunitCommons.ThrowWebserviceException. Trap the error with 'CustomWithRollback' setting. This causes the webservice object structure to rollback... BUT... it leaves your lists with to committed objects intact....AND.....gives you the oportunity to finalize the flow in what way you would like it to end. Add business rule violations to the message or state 'Business object upserted'

  6. Commit the objects in the 'toCommit' lists

That's it Folks

answered
0

Is it a solution to have a boolean attribute called (Inserted By Webservice) default to true and let the microflow handle the upsert in the following way:

  1. Find existing to update and delete the record that the webservice created
  2. If not found, change the [Inserted By Webservice] to false

In both cases business logic needs to be checked and in case of an error you return this over the web service (or enter an error state or whatever you do to handle errors).

answered