eMagiz Mendix Connector 3.0.0 -> 5.0.0

Last modified by Erik Bakker on 2024/09/09 12:23

This document describes the difference between the 3.0 version of the eMagiz Mendix Connector and the 4.X and onwards versions of the eMagiz Mendix Connector. On top of that it describes the checks and balances one has to go through while migrating from the 3.0 version to a newer version.

1. Positioning

This packages has been created to support clients that are moving towards Mendix 8 in their environment. The latest version of eMagiz has been upgraded to use AMQP queues, which effectively means that direct connections from Mendix to onramp and offramp queues can be made. This has a positive effect as less effort is required in Mendix to interact with eMagiz and there is an easier management of the environment as only the infra flows need to be deployed (no exit and entry flows managed in Mendix).

To take benefit from this, eMagiz has released this version to take the first steps in this direction. Below are some more details and instructions to use this new version. Please read these carefully.

Warning

This version removes the web service layer from the eMagiz Mendix Connector. Mendix now connects to the eMagiz bus directly using Java Actions in microflows. The first upgrade to this new version may take more time for development and testing than previous updates of the eMagiz Mendix Connector. After that, however, it should be easier in use for both Mendix and eMagiz developers.

Please find the package on the usual location: Under Deploy > On-premise > Runtime downloads tab

2. Comparison

 Mendix V6/V7 Connector Mendix V8 Connector
    
 Messages received in XML   Messages received in XML, JSON or Data Model
 Web service required to receive messages. For sending messages, a Request Handler in the Mendix model is required  Direct connection to the eMagiz queue (onramp/offramp) made via Java Action
 Each flow (exit, entry and infra) needs to be deployed  Only infra flow needs to be deployed once, microflows connected to the queues directly
Incoming webserviceMicroflow - Java action details 

3. Migration Path

  • Download the package and update the eMagiz Mendix Connector. If you are unsure how, please check out this microlearning
  • Locate the name of the queue that interacts with Mendix web service currently in place
  • Remove the Web service components in the Mendix model
  • At the point where this web service component was called, replace it with the appropriate Java action from the Connector module. Use the queue name located in the first step.
  • Use the configuration items of the Java action as described in the approriate microlearnings
  • Test if the messages are properly working

Key considerations

  • Check if [%CurrentUser%] is not used in the microflow when processing incoming messages. Mendix loses this value when using a Java action microflow. An error message is generated and the message is not processed.
  • Understand the impact of the user that is updating/creating the domain model object. The web service user is no longer used to update/create the domain model object
  • A best practice can be to store the XSDs of the various integrations into the resources folder of the mendix project so that the entire team has access to the latest
  • During restart of the Mendix application, there is no consumer on the synchronous response queues. Once the first message is processed, the consumer will become active. eMagiz alerting will trigger on this scenario which can be considered a false positive.

4. Key takeaways

Please take care of the following items when you start to use this version of the Connector to ensure you can use it properly

  • Use supplied Java actions in the eMagiz Mendix connector to set up the connections
  • These 2 libraries could cause issues with the current version of the Connector - please evaluate the necessity of these before deleting them
    • xerces.xercesImpl.2.8.1.jar
    • xmlbeans-3.0.1.jar.ExcelImporter.jar
  • Make sure that you configure the exits in eMagiz correctly when using the latest version of the eMagiz Mendix Connector.

5. Addendum eMagiz Mendix Connector 5.1.0

With the release of the newewst version of the eMagiz Mendix Connector a couple of things have changed.

  • On project startup the connector-infra configuration is downloaded, installed, and started automatically.
    • When it is not possible to retrieve the active release, the previous connector-infra will be used.
    • The Configuration Overview snippet is back so you can download the release if needed.
  • Improved exception handling for synchronous entry integrations.
    • Standard eMagiz bus exceptions are recognized and converted into Mendix exceptions.
    • Improved way of working with synchronous exits and entries in combination with the import and export mapping (or the absence of them)
Information

Note that this is a brief description of how to migrate from 3.0.0 to a higher version of the eMagiz Mendix Connector. For a full migration path from 4.2.0 towards 5.X.0 please see this migration path

5.1 Infra download, installation and starting

In older versions of the eMagiz Mendix Connector (3.0.0 and lower) you always needed to download the .emc package, manually upload it in Mendix and start the Infra flow by hand.
With the introduction of this release we have made a change that automatically downloads, installs and starts the Infra flow belonging to this specific Mendix application.

emc8-after-startup-retrieve-infra.png

This way you never have to execute those steps and eMagiz ensures that the Infra flow is the first to start up before any exits are registered.
To make this possible we have added logic to the AfterStartup microflow of eMagiz to retrieve the properties from eMagiz, download the infra and start the infra.

In case there is a problem with internet connectivity or you simply cannot reach eMagiz, the microflow ensures that the latest known infra will be started up.

6. Suggested Additional Readings