All IT leaders face challenges of outdated technology. Sometimes it’s time to build or buy a new application. But nowadays, it might make more sense to refresh the new old one. I explore those challenges and provide real client examples where I’ve used low code to help in both cases.
I share my thoughts on the recent acquisition of AppGyver by SAP and how that does or doesn’t relate to their SOLEX partner, Mendix.
The world is battling a war on two fronts: our health is threatened by COVID-19 and our economies have slowed and even stopped in certain sectors. As an App Developer, does my work really matter in such times?
After years of delivering, leading, and coaching leaders in Rapid App Development, I give you my perspective on what skills and profile it takes to be a ‘Great’ RAD Maker.
It’s been 1 year since I first wrote the post, “Extending SAP: Fiori or Mendix?” and a lot has changed. Because of the changes, this older post has gotten a lot of renewed interest so I thought I would take a look at my opinions from a year ago and see if they differ. If you haven’t already, please refer to the original article to have context for this one.
IT should be an expert “SWAT” team with precise skills to tackle the toughest app challenges, not a bottleneck to solving business problems.
When I first began using Mendix tools and creating Rapid App Dev projects, I was coming from a BI/Analytics career. I was very comfortable with SQL and immediately gravitated towards using it in Mendix as OQL Data Sets. I wrote a few other blogs on here (just search the tag “OQL”) and view some write-ups. Now we are up to v8.2 as of this writing and OQL/Java data source still exist as well as the reports. Do they still make sense?
Yesterday I was writing a report in Mendix for one of my clients and I hit a few different walls. For those that have worked with OQL and Mendix, you've undoubtedly hit the same walls. I searched for some help and frankly found very little. That's probably because it's a lightly used feature in the platform and therefore hasn't gotten a lot of attention from the development team for quite a while, which I completely understand, but I figured that as long as I'm using it and learning more about it, I should capture what I'm learning to help others out there that are hitting those same walls.
A month or two ago I wrote about using Document Templates for reporting. At that time I was pressed for time and needed to get a few reports in PDF form out the door. I even commented that I had tried to use the Report Pane and OQL built into Mendix but struggled with the process and didn’t really have time to dive into figuring it out. This past week, however, I couldn’t build the reports I needed to do using Data Grids or Document Templates. I went back to OQL feeling confident I could write the syntax to achieve what was needed and after a day and a half of trial and error, I figured it out. I’d like to share what I learned.
There will come a point during your project where the users will start to ask about getting information back out of this new, slick Mendix application that they are all putting data into. As a BI professional, I’m not talking about OLAP models and prediction modeling. OLTP (On-Line Transactional Processing) applications like the ones you build with Mendix are all about data capture and workflow transformation. But every mature application offers its users some ability to report on the information within it. I’m going to describe one method I use for building these reports in this post, so if that interests you read on!
