Last modified by Erik Bakker on 2025/02/25 16:09

Show last authors
1 {{container}}
2 {{container layoutStyle="columns"}}
3 (((
4 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.
5
6 == 1. Positioning ==
7
8 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).
9
10 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.
11
12 {{warning}}
13 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.
14 {{/warning}}
15
16 Please find the package on the usual location: Under Deploy --> On-premise --> Runtime downloads tab
17
18 == 2. Comparison ==
19
20 | Mendix V6/V7 Connector| Mendix V8 Connector|\\
21 | -- --| -- --|\\
22 | Messages received in XML | Messages received in XML, JSON or Data Model|\\
23 | 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|\\
24 | Each flow (exit, entry and infra) needs to be deployed | Only infra flow needs to be deployed once, microflows connected to the queues directly|\\
25 |Incoming webservice|Microflow - Java action details |
26
27 == 3. Migration Path ==
28
29 * Download the package and update the eMagiz Mendix Connector. If you are unsure how, please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Legacy Functionality.novice-mendix-connectivity-update-emagiz-mendix-connector.WebHome||target="blank"]]
30 * Locate the name of the queue that interacts with Mendix web service currently in place
31 * Remove the Web service components in the Mendix model
32 * 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.
33 * Use the configuration items of the Java action as described in the approriate [[microlearnings>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Mendix connectivity.WebHome||target="blank"]]
34 * Test if the messages are properly working
35
36 **Key considerations**
37
38 * 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.
39 * 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
40 * 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
41 * 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.
42
43 == 4. Key takeaways ==
44
45 Please take care of the following items when you start to use this version of the Connector to ensure you can use it properly
46
47 * Use supplied Java actions in the eMagiz Mendix connector to set up the connections
48 * These 2 libraries could cause issues with the current version of the Connector - please evaluate the necessity of these before deleting them
49 ** xerces.xercesImpl.2.8.1.jar
50 ** xmlbeans-3.0.1.jar.ExcelImporter.jar
51 * Make sure that you configure the exits in eMagiz correctly when using the latest version of the eMagiz Mendix Connector.
52
53 == 5. Addendum eMagiz Mendix Connector 5.1.0 ==
54
55 With the release of the newewst version of the eMagiz Mendix Connector a couple of things have changed.
56
57 * On project startup the connector-infra configuration is downloaded, installed, and started automatically.
58 ** When it is not possible to retrieve the active release, the previous connector-infra will be used.
59 ** The Configuration Overview snippet is back so you can download the release if needed.
60 * Improved exception handling for synchronous entry integrations.
61 ** Standard eMagiz bus exceptions are recognized and converted into Mendix exceptions.
62 ** Improved way of working with synchronous exits and entries in combination with the import and export mapping (or the absence of them)
63
64 {{info}}
65 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>>doc:Main.eMagiz Support.Migration Paths.migration-path-emagiz-mendix-connector-420-to-500||target="blank"]]
66 {{/info}}
67
68 === 5.1 Infra download, installation and starting ===
69
70 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.
71 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.
72
73 [[image:Main.Images.Migrationpath.WebHome@emc8-after-startup-retrieve-infra.png]]
74
75 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.
76 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.
77
78 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.
79
80 == 6. Suggested Additional Readings ==
81
82 * [[Migration Paths (Navigation)>>doc:Main.eMagiz Support.Migration Paths.WebHome||target="blank"]]
83 ** [[eMagiz Mendix Connector 4.2.0 -~> 5.0.0 (Explanation)>>doc:Main.eMagiz Support.Migration Paths.migration-path-emagiz-mendix-connector-420-to-500||target="blank"]]
84 * [[Novice Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Novice.WebHome||target="blank"]]
85 ** [[Mendix Connectivity (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Novice.Mendix Connectivity.WebHome||target="blank"]]
86 * [[eMagiz Mendix Connector (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?text=%22emagiz%20mendix%20connector%22&f_type=DOCUMENT&f_space_facet=0%2FMain.&f_locale=en&f_locale=&f_locale=en&r=1||target="blank"]]
87 )))
88
89 (((
90 {{toc/}}
91 )))
92 {{/container}}
93 {{/container}}