Enabling flexible Mendix enterprise deployments with dynamic app service locations

Skip navigation

Enabling flexible Mendix enterprise deployments with dynamic app service locations

Enabling flexible Mendix enterprise deployments with dynamic app service locations by Reinout van.Schouwen

In a typical enterprise Mendix deployment, it’s not just one or two apps working independently. Often, we see multiple apps working together and sharing resources. Adhering to a component-based approach, in this scenario multiple Mendix apps behave as components in a larger system. Together, the components can be combined in various ways to create full applications.

Synchronization between the individual components may happen by pull services for data retrieval and push services for updates. This type of architecture is often referred to as ‘service-oriented architecture’ (SOA).

App Services

The natural way for Mendix apps to publish and consume services among each other is by way of App Services.

Unique to Mendix, App Services let you expose data and functionality of your apps as microservices, and mix and match the services in your app ecosystem in every imaginable way. The best part: you don’t have to worry about the complexity of web services, XML mappings, and schemas.

App Services, like traditional web services, have endpoint URLs where they can be accessed. The endpoint for accessing an app service can be overridden at design time by specifying a constant with the actual location. However, for enterprise deployments as discussed above this is not always flexible enough.

Old situation: Yes or No

In Mendix 5.14 and below, the setting to override an app service location looked as follows.

Override location Yes or No
The old way to configure app service locations.

In the Settings tab of a consumed app service, we can specify whether we want to override the app service location. If we choose Yes here, a constant (in this case @AppServiceLoc) is required that will determine the endpoint location for all calls to this app service. In the No case, the default location, for instance http://localhost:8080/ws/TestAppService/1/soap1, is used.

The following diagram illustrates the old situation where you have multiple providers and consumers of an app service X. Consumers of X only know about a single provider of service X at a time:

App Service consumers only call a single provider

Introducing the Parameter

From Mendix 5.15 on, the Modeler gives you the choice between three options:

  1. Default Equivalent to the previous No option. The app service location is not overridden.
  2. Constant Equivalent to the previous Yes option. The app service location is overridden by a global constant.
  3. Parameter A special parameter, AppServiceLocation, is introduced in every call to an action which the consumed app service makes available.


Default - Constant - Variable
The Parameter option is introduced

Using the third option, Parameter, adds the flexibility to determine the location of the app service at runtime. Now we can launch new instances of our Mendix apps and let them synchronize their data with others, without having to edit the model!

When you upgrade an existing project containing a consumed app service, your settings will be preserved and converted to either Default or Constant.

The following diagram shows the new possibilities: each App Service consumer can consume any number of instances of service X. A new instance of a service provider can register itself with a consumer so it knows about which providers to call.

App Service consumers can now call any provider of service X.



The following example shows how an app can call the ‘Register’ action on multiple instances of the same app service on different endpoints by iterating over a list of app node locations. The endpoints are passed on as value of the AppServiceLocation parameter in the call action.

In the call action itself, you should enter the value of the AppServiceLocation parameter as an expression. The value can be a literal String, but to benefit from the dynamic nature of the location override, you will probably want to use a variable.

The AppServiceLocation parameter should be given an expression as value.


We have discussed an improvement in Mendix 5.15 that allows you to specify app service locations by using a parameter with a value that is determined at runtime. This adds flexibility desired for service-oriented enterprise solutions. We hope you like it! Please leave your comments below.

Author Info

Reinout van.Schouwen