This article aims to provide a summary of all the solutions available in Mendix marketplace and Snowflake marketplace to perform integration between both the platforms. Before we deep dive-in further, let’s quickly understand in brief what are these platform —

Mendix is a platform used to build web, native, and hybrid applications through a low-code/no-code approach. It is primarily a cloud-based solution that operates in PaaS, IaaS, and on-premises models. Using the low-code approach, it aims to support rapid application development (RAD) and follows Agile methodology with an incremental/prototyping model in the SDLC for building applications.
Every Mendix application uses SQL DB for storing structured data and file storage documents server to store unstructured data.

Snowflake is a cloud-based data platform used to store both SQL and NoSQL records. It primarily operates on a PaaS model, with its storage layer hosted on one of the major cloud providers — AWS, Azure, or GCP. All data stored in Snowflake can be queried using Snowflake (similar to SQL) statements and accessed through the Snowflake UI (Snowsight), external connectors/drivers, or via the CLI.

As of now, we have 3 modules in total offered by Mendix to perform the integration with Snowflake -
Referrence — https://docs.mendix.com/appstore/snowflake-modules/

1. Snowflake REST SQL Connector
   - Available in Mendix Marketplace
   - Can perform read and write operations with Snowflake
   - Uses Https based REST approach to interact with Snowflake.
   - Link — https://marketplace.mendix.com/link/component/225717
2. External Database Connector
   - Available in Mendix marketplace
   - Can perform read and write operations with Snowflake
   - Uses JDBC driver approach to interact with Snowflake
   - Link — https://marketplace.mendix.com/link/component/219862
3. Mendix Data Loader
   - Available in snowflake marketplace
   - Can perform write operations with Snowflake
   - Uses Odata approach to fetch data from Mendix application and then directly ingest into Snowflake
   - Link — https://app.snowflake.com/marketplace/listing/GZTDZHHIE0/mendix-mendix-data-loader

Let’s quickly explore what are the capabilities offered by each of them understanding in form of pros-cons :

Snowflake SQL Rest Connector -

Pros:
- Authentication with an RSA key pair according to PKCS #8 standard
- Authentication with OAUTH through an OIDC provider
- Execution of single SQL statements
- Synchronous execution of calls
- Execution of a Cortex Analyst query
- Convenient to create SQL queries in microflow
- Doesn’t have any dependencies on any snowflake jars or libraries.
- Can add multiple authentication for configuration and dynamically call SQL statements via identifiers.

Cons -
- Complex execution of calling SQL statements asynchronously.
- Slow performance can be observed in case of congestion.
- Can be inefficient if multiple SQL statements are concurrently called for execution asynchronously.

External Database Connector —

Pros:
- Authentication with an RSA key pair according to PKCS #8 standard
- Supports synchronous and asynchronous executions of SQL calls.
- Supports execution of multi SQL statements via CTE.
- Supports calling SQL statements of stored procedures.
- As compared to SQL Rest Connector, this can be more performant in case of congestion as statements are getting queued over jdbc pool.

Cons:
- Queries need to be pre-defined in external database object, before calling it inside microflow, can be inconvenient for writing complex microflows.
- Doesn’t allow to configure multiple authentication and dynamically use it to call snowflake SQL statements.
- Have dependencies on snowflake-jdbc drivers, hikari-cp libraries, bounty case files for generating decrypted private key for authentication.

Mendix Data Loader —

Pros:
- Can be useful for ingesting bulk data of Mendix application into Snowflake databases
- Uses OData, hence Mendix application needs to publish OData service which will be consumed by this connector to fetch data.

Cons:
- Doesn’t support real time writeback of data to Snowflake, as Snowflake task will be pulling data from Mendix database on interval basis.
- Cannot use this module to read existing Snowflake records inside Mendix application.

Conclusion:

Hope this article gives you an idea about the modules and able to decide the approach of integration with the capabilities mentioned. You can refer below documentation for detailed understanding -
1. Snowflake SQL Rest Connector — https://docs.mendix.com/appstore/connectors/snowflake/snowflake-rest-sql/
2. External Database Connector — https://docs.mendix.com/appstore/modules/snowflake/external-database-connector/#introduction
3. Mendix Data Loader — https://docs.mendix.com/appstore/modules/snowflake/mendix-data-loader/

Hello folks. You must be wondering why an article on this topic… Well, let me share a story. Recently, the CYS department audited our Mendix cloud application and shared some vulnerabilities, asking about the behaviour of Mendix runtime. In their logs, they reportedly raised questions about this XAS service.

Well, this allows us to deeply study the XAS service and try to decode this.

What’s in there for you?

Honestly, this blog is more theoretical and aims to share the findings discovered and unwrap the inner workings of the Mendix architecture. With this knowledge, you will be able to handle your application security more wisely.

Introduction

XAS is the private HTTPS REST API endpoint used by the Mendix client to communicate with Mendix Runtime. It is one of the request handlers offered by Mendix. This is sent as a form of API request and is an important element of the Mendix architecture. Each type of call to this API is called an action, and necessary parts of the state are sent along with it. You can inspect XAS requests in the Network tab of your browser’s developer tools and filter out requests to the XAS path.

Whenever a XAS action (such as a microflow call) is triggered, Mendix Client also sends the state. Mendix Client does not send the entire state to the runtime, as this would create major performance issues. Mendix decides which parts of the state should be sent by analyzing each microflow during the deployment of the applications.

Decoding XAS request

The above image illustrates how an XAS request is made within the Mendix application. The left part represents the XAS request made, and the right part represents the response application received from Mendix runtime on making XAS request. The responses varies on the basis of the action parameter.

Let’s consider another XAS request where we have action as runtimeOperation,

In both images, you will find a similar request body (the JSON one)made by XAS. Let’s focus on that and decode what that means:

1. The action property indicates to the Runtime that the request is for a Runtime Operation, as specified by the operationId property.

The Runtime queries its registry to locate any Runtime Operation associated with the ID “3ow5sZxTSUW01B+FefxS2Q”. In this instance, it identifies an operation type, “Create”.

1. Under the params section, parameters can be transmitted to the Runtime if required. In this example, no parameters are necessary.
2. As indicated, the majority of the information concerning the Runtime Operation is maintained internally within the Runtime. This approach minimizes the amount of data transmitted in the client’s request, thereby enhancing security. However, this can also make debugging the application more difficult.
3. To assist with debugging, you can set the IDResolution log node to ‘debug’. This log node records every time a new Runtime Operation ID is resolved to its corresponding Runtime Operation. It includes the stored registration details and any parameter inputs received from the Client.

Additionally, the Runtime Registry is stored in the app’s deployment directory under model/operations.json for debugging purposes

For this operation type, this will follow the below call between Mendix components,

This resolves to the following in the Runtime:

{
    "constants": {
        "ObjectType": "DataProduct.Domain"
    },
    "id": "3ow5sZxTSUW01B+FefxS2Q",
    "parameters": {},
    "type": "create"
}

One thing to note from the above models.json file, for every operation ID we have allowed UserRoleSets, which is nothing but an access rule defined at the Microflow level, and from this, we understand that Mendix runtime holds all the microflow access rules over there.

Conclusion

I hope this article was able to provide you insights on XAS service in depth.

Referrences

Mendix Blog — https://www.mendix.com/blog/the-art-of-state-part-1-introduction-to-the-client-state/

Mendix doc — https://docs.mendix.com/refguide/communication-patterns/

In part 1 — https://medium.com/@nkhard98/mendix-team-server-migration-svn-to-git-part-1-46eadedccec2

We understand how one can migrate their Mendix application configured on SVN server to Git. This article aims to share the experience of version controlling strategy which one can find after the migration.

In part 1, I mentioned about how I was benefitted with Mx command line tool, well let me reveal this part over here.

After you migrate the application, you will observe some changes under Version Control of your Studio pro. If you go under “Merge changes here”, you will notice something different than usual SVN server options,

If you have been working in Mendix for a while that too in SVN, you must have came across “Advanced merge” in SVN, where it gives you the possibility to import changes of certain revision range by specifying start revision and end revision.

But guess what, you won’t be seeing this option anymore in Git. Honestly, I don’t know why this has been discontinued but it was a great feature and for me personally, that was one of the lifeline feature for transporting codes from development branch to UAT and then further to prod.

Seeing this, I was shock and made me hard to believe, but after exploring community and slack channel, I need to accept this.

Now let’s talk quickly about the other 2 options, Merge feature branch and port fix.
1. Merge feature branch — Will allow you to include all the changes of the custom branch to the current branch.
2. Port fix — Will allow you to import only single revision change from the custom branch.

For my usage, none of the above 2 matches my need, where I want to import only partial changes comprising of multiple revisions to the current branch.

My approach regarding version control is simple, for any mendix projects, I only have custom branches each for my app environment. For example, If my app has test,accp and prod environments. Then I will be having individual code branches for each of the environment and will be deploying that respectively.

One thing I made sure was I won’t be compromising the branch setup because of this and then after some research, I found out a way which closely work like advanced merge SVN and that is Mendix command line tool — “mx merge”

Reference — https://docs.mendix.com/refguide/mx-command-line-tool/merge/#merge

The above link clearly explains how the process works and this actually solves my problem. One may argue, this is nothing just a Merge feature branch option only but the algorithm used beneath varies actually.

This command works differently than the normal version-controlled merges you can do in Studio Pro. While Studio Pro does a real merge of one branch into another, this command runs the merge algorithm over three .mpr files that do not even have to be version-controlled.

This brings to the end of the topic, I hope you may find the information useful. Feel free to reach out at — https://www.linkedin.com/in/nkhard98/

In this article, we will mainly try to understand how one can plan for migrating their Mendix apps configured from SVN server to Git.

Introduction —

With Mendix 10 around, we have seen a lot of changes has been implemented within the platform and one of them is Mendix 10 will now only support the Git server.

Well, the Git server was introduced in Mendix 9 itself and lately projects have been created within that which comes with advanced version controlling techniques like mx diff, mx merge etc by the Mx command line tool for Mendix projects. (I personally was benefitted alot… let’s keep it for part-2).

Anyways, sorry for going off-track, with this change we have legacy apps configured on SVN and those apps need to be eventually migrated to Git server and in my opinion, the sooner you do it the safer you will be in future because this might get more complicated with the project dependencies….

Approach —

It depends on which stage your project is but to achieve this, I would highly insist before you start the actual migration. Make sure your project is already fulfilling below criterias (The criterias are referred from — https://docs.mendix.com/developerportal/general/migrate-to-git/#apps-eligible-for-migration, I advise you whenever you are reading this, please refer to this site as the criteria might get updated from time to time).

Note : The criteria mentioned below are as per the dated : 22nd Feb 2025, advised to recheck with above URL.

Criteria -

1. The main line of the project should be in version Mendix 9.24.28 or above
2. All the other branches should be in atleast 9.12 or above.
3. The size of the mpr file (One can check in app directory of the project) should be less than 400 MB.

4. (Optional) Also, if you plan to migrate your app with entire change history then your repository size should not exceed more than 3.5 GB (this is something Mendix can only check within backend, although there are some ways you can roughly estimate if it has occupied that much space already).

Now that we know criteria, the biggest questions what if my project doesn’t fulfill the above criteria and in this article we are mainly going to understand that -

Criteria 1 and 2 are pretty straightforward and I believe one shouldn’t face much issue while upgrading your apps if your project has been designed mainly keeping in mind the Mendix best practices.

Criteria 3 is something the projects usually don’t hit the benchmark of that but if your project has exceeded the limit then let’s understand how to overcome that.
So, before we understand the solution let’s understand first what is MPR ? MPR stands for Mendix Package runtime in simple terms, whatever we build inside Studio Pro all the code gets stored gets in form of Mendix binary format which is interpreted or excuted by Mendix runtime. For better understanding, refer below paragraph -

An app modeled in Mendix is traditionally stored in a single .mpr file. This is essentially a database which contains data for all documents, such as microflows, workflows, pages. As the Mendix app is stored in a single file, your version control system only sees that a single file is changed. To show the exact documents that have changed inside the .mpr file a tool that comprehends the format is required, such as Studio Pro.

The above information has been taken from — https://docs.mendix.com/refguide/troubleshoot-repository-size/#traditional-mprv1-format

Now that we know what MPR is, we can actually think of reducing its size and I believe before we go for advance optimization, you can actually think of optimizing the size by removing unused Mendix objects like modules, pages, microflows, entities etc…. because that will directly affect the size of mpr file as it will have less objects to store basically you are reducing the code usage size.

Even after doing this, if you are unable to bring the size under 400 MB then you have to go for advance optimization which is optimizing the MPR file which is also known MPRv2.
To achieve this, you need to refer below documentation — https://docs.mendix.com/refguide/troubleshoot-repository-size/#decreasing-mprv1-file-size

I won’t go deep futher, but I will quickly outline the difference in working of MPRv1 and MPRv2, while v1 stores all the changes in a single mpr file basically re-writing the entire changes on latest revision, v2 will actaully maintain a delta copy of the base version of .mpr file which gets created during project initialization. So every time you make changes to the app, your base mpr will stay as it is but the another mpr file will be holding changes wrt to base mpr and that will keep growing.. For more info, please continue reading the above URL

Note : In article, they have mentioned this option is available for Mendix 10.18 but you will also see this in Mendix 9.24.28 onwards…

With fulfilling above criterias, your app will become eligible for migration and this will be shown under Team server of Mendix sprintr project and as of now, only Scrum Master of the Mendix app can perform migration hence scrum master can only see this under Team server.

Once you click on “Migrate to Git” option, you will be redirected to another application of Mendix where it will perform migration and before it does that, it will check the eligibilty criteria stated above and then only it will proceed to the next step to choose how want to procced further with migration.

Once you reach this page, you will see an option to perform migration with 2 approaches — “Continue with history” and “Continue without history”. To understand more, please refer — https://docs.mendix.com/developerportal/general/migrate-to-git/#eligible-for-migrating-without-history

Here the optional criteria, will come into picture, if your app repository size is more than 3.5 GB (your repository will mainly comprises of .mpr file,userlib folder, data folder stored under deployment folder, your javasource,javascript,theme,theme-source folders) then your app won’t be eligible for migration with history, hence overall size of this shouldn’t exceed more than 3.5 GB across all the branches of the app.

Once you click on “Migrate to Git” after you reaching the final step, it will enable migration where your app environments will still be running with zero downtime but all your deployment activities will be blocked and your code in machine will become stale. You will be receiving mail notifications about the process start and end, as per the logic app without history will get migrated quicker as compared to app with history.

Congratulations…. Your app will be migrated and now you have to download it again from team server using studio pro.

Thanks for reading the article or blog. I will be writing another part of this, where I will share my experience what changes one will observe after migration and how to adapt with them. So stay tuned and see you on another one. Bye and take care!.

Introduction -

• The Mendix Data Loader, developed using Snowflake’s Native App Framework, is designed to streamline the extraction of operational data from Mendix applications directly into the Snowflake environment.
• It is tailored for data engineers, this connector simplifies the data migration process, ensuring efficient and secure data transfer from one or many Mendix apps into a structured Snowflake database.

Pre-requisites -

• To use the Mendix Data Loader, you must have the following:
• A Mendix application with a published OData service that includes exposed entities.
• A Snowflake environment.

Licensing and Costs –

• The Mendix Data Loader is covered under the Mendix EULA. While the loader itself does not incur additional costs, operating within Snowflake may incur a usage cost. For more information, refer to the Snowflake pricing documentation.
• Depending on your use case, your deployment environment, and the type of app that you want to build, you may also need a license for your Mendix app. For more information, refer to Licensing Apps.

Architecture

• It will mainly involve three components — Mendix app, Mendix Data Loader, and Snowflake Warehouse.
• The Mendix app will be sending its application data to the Mendix data loader or the data loader can request data from the Mendix app on an interval basis.
• When the Mendix data loader receives data from Mendix, then it will write the data to the snowflake tables.

Link to Part 1 — https://medium.com/@nkhard98/unleashing-power-of-mendix-with-snowflake-part-1-cddba4a1fc29

In the last post, I quickly discussed using Snowflake DB over native Mendix DB (which is provided by Mendix cloud platforms) for big data applications. This leads to an interesting question if both are storing data in tabular format, then how does Snowflake DB have an edge over Mendix DB? We understood one aspect of it but there is also a difference in how their data get stored physically and we are going to compare in this post.

Mendix — By default, Mendix cloud platforms store data using PostgreSQL DB and in it, the rows of the table are stored physically into segment files of fixed size and each segment file comprises fixed-size pages. These files can be stored in a contiguous or dis-contiguous fashion. This is the concept of segmented paging under memory management. At this postgres manages all of this for Mendix and whenever Mendix wants to retrieve data from the table, it instructs Postgres to fetch all rows of the tables from all the segment files and then that data is passed to Mendix memory by Postgres and then further data operations (like pruning) /transformation(like aggregation) happens. This entire process is very quick but if we work on rows of a table having 3 billion rows you can imagine the performance impact.

Snowflake — On the other hand, stores the rows of a table into something called micro partitions which are continuous units of storage. These partitions follow the columnar storage principle. The rows of the table are broken down into partitions and every partition’s metadata is managed by Snowflake which contains information on the min and max value of every column stored inside it which will be helpful in pruning operations, as the number of distinct values and other additional properties, which makes query processing and transformation operations more efficient and faster for larger datasets.

For more information, you can refer below articles for a better understanding -
Mendix — https://lnkd.in/gak4Bmwu.
Snowflake — https://lnkd.in/gXUn8ZV9

Hey Folks, Mendix is a great technology for building applications, but what if you have been asked to build apps for large datasets or big data over Mendix platform servers?

Well, we can still build a solution but it might not be a great approach in terms of cost and performance.

One of the solutions can be built using Snowflake Warehouse instead of Mendix DB. Mendix will be mainly acting as a front end over here and Snowflake will be used as a backend.

Let’s have a quick comparison -

1. Costs — Snowflake offers storage costs ranging roughly from $25 to $40 per TB storage per month based on the location you pick. While Mendix involves file and database storage costs in its plan the storage they offer is combined which roughly starts with 15GB. You can buy additional storage every year and that is also not cheaper. Hence Snowflake does have a huge advantage (One can argue for compute costs and we will see in the performance section).

2. Performance — Mendix uses a combined approach of OOL+SQL to retrieve data from Mendix DB. On the tool level, we define the retrieve data path via the ‘retrieve’ activity in microflow/nanoflow and use xpath when we want to do selective point lookup. Now internally these xpath and retrieve logic from flows get transformed into OQL and then further into SQL before it is queried to Mendix DB. After successfully queried, these rows get converted into Mendix objects before the contents get loaded into UI. This consumes time and degrades the performance.

As per the Mendix experts, we can speed up things by writing OQL directly from the tool, but it can be a cumbersome task. Another approach is to have those entities or tables stored in a denormalized approach and then use retrieve activity but again this is not doable every time.

Here Snowflake can be useful since we need to pass SQL directly to query data, one can write efficient queries to retrieve data (this is further optimized at the service layer of Snowflake by query optimizer). Furthermore, for advanced analytics Snowflake offers various functions or methods like CTE which makes working on data simpler.

Coming back to the compute cost, Snowflake charges for processing, and hence once we have processed data, we can have it cached in Mendix DB for a particular session. Hence ending up saving some bucks and more importantly we have an app running much faster.