Enabling flexible Mendix enterprise deployments with dynamic app service locations

on April 14, 2015

Share:

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). Please refer to the presentation ‘Divide and Conquer‘ to learn more about the advantages of SOA and loosely coupled components.

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. Please watch this presentation at Mendix World 2014 which is a good start if you’d like to learn more.

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:

appservice_diagram_old

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.

appservice_diagram_new

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

 

Example

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.

CallAppService

The AppServiceLocation parameter should be given an expression as value.

Conclusion

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.

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Reinout van.Schouwen

About Reinout van.Schouwen

At Mendix, Reinout works as a software developer in the Integration team at R&D. Reinout has a background in Artificial Intelligence and has worked as a scientific programmer at the Huygens Institute and the Leiden University Medical Center. He lives with his girlfriend Sanne and 3-year old daughter Odette in Rotterdam, NL. In his spare time, he volunteers for the Rotterdam department of the Dutch Green party where he fulfills the job of treasurer.