Re-thinking IFS technical delivery in the new world of IFS Cloud

Ryan Ibbitson is  a contract IFS Developer experienced in manufacturing, construction, engineering and energy industries. He has deep expertise in producing customisations across a wide range of modules including HR / Payroll, Finance, Supply Chain Management, Manufacturing and Service and Maintenance.

Ryan takes pride in his customer-focused approach, delivering solutions fit for ‘business as usual’ and supportable in the long-term. Freelance for two years, Ryan is currently working with a leading engineering services firm on their IFS Cloud implementation.

The IFS technical landscape has changed

In IFS Cloud the codebase is open. You have a lot more flexibility and you can do a lot more with the user-interface. This creates opportunities for IFS customers, and also brings new risks. In this blog Ryan explores the impact on developers and highlights the importance of having a solid technical strategy across the team. 

The major difference is the IFS Cloud web app

The database underneath is 99 per cent the same. The way the front end interacts with the database is what’s changed. 

In earlier versions you had an installed application that was making direct database calls. The way Cloud works is you have a web app that interacts, and the packages inside are a barrier between the web app and the database. It’s a layer of protection that really changes the way you do user permissions. 

IFS Cloud gives you more flexibility, and more capability to customise in a structured way. 

Building a reliable mechanism for code delivery

There’s been a shift in how you do IFS code releases. It used to be that you’d add everything to ACP, and use a manual release process to go and import those. Now because you’ve got access to the core code in Build Place, you’re building everything into a package which is then built into a release. IFS then validates that package. You build the delivery, and it’s all segregated from your use environments. You can look at it before pushing it into your dev test environments. It’s much more secure. You can make sure it all hangs together, and it pre-checks itself. 

There can still be configurable items there, like quick reports and lobbies, and a few other pieces that can still go in ACPs and still require manual delivery.  However, you can build them into your release delivery through Build Place.  It seems like people haven’t completely picked up on this, but it is possible. 

You’ve lost the ability to quickly rectify any errors

In Cloud there are CRIM events that can still be done as configurations, where you would write the PLSQL block and insert it to the event, but this functionality is being deprecated.

So now that CRIM event is more suited to being a  modification. Rather than an event that creates a database trigger, you’re going into the IFS API. You’re extending the code to add the functionality. 

This means you lose the ability to quickly rectify any errors. So if something gets through testing before it is spotted, you’ve lost the ability to natively turn it on and off. (You can switch a configuration on and off.) But with a modification you have to go through the whole fix, or remove it and build a delivery. Then that has got to go to development testing, and you’ve got a lead time on that. 

This feels like an issue that has been slightly overlooked by IFS, and it’s something that can impact every upgrade to Cloud. One small example could be in the run up to go-live, there’s an event you need to switch off during data migration loads. When you upload a bulk set of data, say thousands of purchase orders, these will all trigger email notifications. You won’t want to send thousands of emails, so you need the ability to switch off notifications, load them in, and switch it back on. 

You’ve got to be really aware you are changing something in the codebase. If you want a way of switching that event off you have to programme that in yourself, this could be  a custom field or a configuration table. There’s no standard, built-in way to do this. 

Workflows hold potential pitfalls 

Workflows are a low code option that non-technical professionals can access through the web app. This is risky. Developing fit for purpose solutions is hard, and you still need to understand the processes behind them. When you do get an error with a workflow it is a generic error. You don’t get a SQL error that gives you specific information. 90 per cent of the time it doesn’t say you don’t have access to this object. It just says you don’t have access. That’s extremely hard for a non-technical person to unravel. If you have technical professionals with product knowledge, use Build Place. It’s more stable. 

Manually typing basic data is a cause of inconsistency

People are still typing basic data into one environment, opening the next next and typing it into that. This can all be added as a script through your release process. This gives you the benefit of consistency all the way through. 

The fettlers need to stop (seriously)

Years ago I worked with a brilliant IFS developer who’s gone on to be a partner in a leading IFS consultancy. He called fiddling around in the back end ‘having a fettle’. The fettlers could get away with it, just about, in earlier versions. But in IFS Cloud consistency really matters. Take lobbies for example. 

One lobby page can have 20 elements. You get a request to add another one to the page. If you were to just add one lobby element on its own, you would have to go into each environment individually, add it to the page, and then sort out the permissions so the right people can access it. Or, you can just add it to the page and export it in full. 

But the problem with that is if someone else has added something to the same lobby page upstream and that hasn’t gone through the process, it will remove their work.

As a developer there is nothing more frustrating than someone saying, “This doesn’t work in this environment, but it does in that one.” 

You need consistency. You need an agreed strategy that is implemented across all consultants, suppliers, everyone.