In this post I will explain how I created a very useful reusable Mendix module for the following user story:

As an admin I want to export some of the application’s data, so that I can easily import it in other environments of the same application.

In Mendix, you can create specific export functionality for your entities, using Domain-to-XML-mappings. However, this is a lot of work for and you would need to develop this specifically to the domain model for each application (or even multiple exports within a single application). Another drawback of this approach is that you can only export a simple tree structure. More complex reference structures, like circular references, are not easy to do: to get an idea of what I mean, look at how the export/import functionality of the DBReplication module in the Mendix app store is implemented.

I wanted to create a generic way to export data. Simply selecting the entities and associations of the objects that you want to export should be enough.

The (meta-)domain model

I created the following domain model that will be used to contain the data for exporting and importing. It is basically an abstraction of the Mendix object model:

Read More

In this post I will explain how to get a dynamic help tooltip in your Mendix UI, without using a custom widget. The result will look like this:

Read More

Consider the user story

As an admin, I want to be able to immediately block a user, so he/she can no longer access the data in the application

You could easily implement a blocking mechanism, using setting the boolean attribute Active in System.User to false.

Note: You could also implement a more sophisticated blocking mechanism yourself, by added your own attribute(s) to Administration.Account, an then do a check on these attribute when the user logs in, as explained in my previous post.

Then, the user will no longer be able to log in. So the user story is now done, right?

No, because  Read More

If you want do some custom checks when a user logs in, it is possible to override the Mendix login mechanism.

With this, you can do a lot of useful things. For example:

• Implement a custom user blocking mechanism, e.g. block all users that are linked to a certain company.
• Only allow users to log in from certain IP addresses
• Dynamically assign user roles when logging in
• Etc. etc. (leave your comment below for more ideas!)

Read More

The Mx Model Reflection module is a technical component from the Mendix App Store that is used in almost every Mendix project. The main reason for this is that other well-known modules from the app store make use of MxModelReflection, such as the ExcelImporter, ExcelExporter, FixedLengthExporter, and DBReplication modules.

It is a very useful component, but what does the MxModelReflection module actually do?

• It allows certain users of the Mendix application to see the module names used in the model.
• Users can select for which modules they want to load the entity information and microflows.
• It adds tables to your database that will save this information.
• By using the objects that represent other entities, there is a meta-model at run-time.
• The meta-model can be used to configure exports and imports of data at run-time, like with the ExcelImporter.

This is very handy! But there are some potential weaknesses:

• When adding this module, you also will add a number of tables to your application database, which is not very elegant. Also, companies may have architectural policy to mimimize the amount of changes to the database for applications that are already in production. So adding new tables that don’t contain business data is sometimes undesired.
• It poses a security risk by allowing some users to see (parts of the) source model of the application. This information could give attackers insight in weaknesses that your application might contain.
• You need to sync the model reflection when you changed something in your model. In every environment (DTAP)… If you forget this on any environment, it can break important functionality, e.g. the ExcelImporter will throw ugly error messages at the user if the model reflection is not synced properly.

In this post I will show a way to get meta-information of your application without using the MxModelReflection module. This will give developers more flexibility and more control over the information shown in the user interface. Also it doesn’t add any tables to the database!

Read More

In this blog post, I will demonstrate a modelling pattern that I often use for importing data from Excel, and explain the choices made. The ExcelImporter component from the Mendix AppStore is one of the most used business components in Mendix. So, as a Mendix business engineer, this one should be in your toolbox! I will use a real-life case to demonstrate how I think you can use it best.

Set-up

The easiest way to add the ExcelImporter module to your project, is to click the ‘AppStore’ button from the Mendix Business Modeler.
The ExcelImporter is listed in the Most popular components. Click it, and then click the ‘Download’ button. Also, read the documentation of the appstore module. After downloading, add the ExcelImport as a new module to your project.

Now, if your project suddenly contains a lot of errors, you are missing the MxModelReflection module. Don’t worry about the errors: just download and add the Mx Model Reflection module from the AppStore, and these errors will be resolved.

The case

Consider the following user story:

As a stock manager, I want to register each delivery, in order to keep track on the stock

From our supplier, we receive an Excel file with delivered products for each delivery. This leads to the following domain model in the module ‘Stock’:

Multiplicity: One Delivery object is associated with multiple DeliveredProduct objects. On delete of Delivery object: Delete DeliveredProduct objects as well.

The DeliveryFile inherits from ExcelImporter.TemplateDocument, which is itself a specialization of System.FileDocument. This allow file uploads/downloads to the Mendix application.

Why is a specialization of TemplateDocument needed? Read More

If you’re developing software in Mendix, you’ll be inevitably using lists in your microflows. If you have a list, but want to use a single object from that list in another microflow, it can be tricky to get that object, because currently, Mendix has no list-indexing microflow-action.

In this post, I will show how you can use a Java action to get an object from a list, using a single line of code, which will work for any object type. And I will also give a solution that doesn’t require any Java-coding and just uses microflows. Read More