Skip to main content

Just a rant for whoever experiences the same.

I'm trying to get IFS to fix exporting and importing ACP's with event actions of type Execute online SQL where the statement has more than 4000 characters.

And the ticket turns into a discussion about why I'm not using workflow and if I can supply a list with issues which caused me to use sql instead of alternatives.

Excuse me what?

The fact here is with the implementation of the workflow in our company we had a huge list of issues and design flaws which I had to call out and struggle to get corrected. And by no means I'd say that in the current state in the version we're about to go live it's a stable solution. I don't get thanks for this, I get to pay to get things fixed and struggle to keep tickets open as well.

For me the problem with IFS in this regard is that they have the balls to say this SQL feature is deprecated while fully knowing that the alternative is a steaming pile of ….. 

Why not be honest and set a date when it can actually be deprecated? Now they are acting like there is an alternative which there just isn't. 

NO, WORKFLOW IN ITS CURRENT FORM IS NOT AN ALTERNATIVE

 

Thank you!

@JoDe I'm with you on this one. Whenever I l needed to create a more complex CRIM, I've always tried to use a WF. And then guess what, all the time there was a commit/rollback in the core code and my WF would throw an error. Therefore, even for my IFS Cloud customers I do event actions that execute a PL/SQL block of code. If/when IFS will put a deadline on when Online Sql actions will no longer be executed, then probably I'll move the PL/SAL code into a DB package and move it across environments as a delivery.

@JoDe I totally agree.

Workflows in current state are not an alternative.

There are multiple scenarios that cannot be converted from PLSQL event to Workflow (and vice versa, there are some cases where you can do something via workflow but not via plsql event).

There are definitely some large holes in the Workflows.  Information message output and detailed error messages stand out as important ones to address.  There are workarounds, but many of them are complicated and antithetical to a “low/no code” alternative to Online SQL.  

Hi All,

While we strive to improve capabilities of Workflows it is important to note that in instances where you cannot achieve the desired functionality a customization (using code) is preferred over adding blocks of PLSQL code into configurations. Adding large code blocks in configurations is complex to manage/audit than having them tracked in version control.

Please follow the guidance given here https://docs.ifs.com/techdocs/24r2/040_tailoring/100_tailoring_overview/#common_scenarios

Thanks,

@Rifki Razick , I get what you're saying here, but as a customer it's incredibly frustrating we're being pushed to use this tooling while it's so incredibly broken and has so many design flaws. 

Why not change the documentation and give your customers clarity? Now we're being pushed to use something which we might need to rebuild to SQL each update? Mind you, not uplift, actually rebuild.

 

Thanks for the feedback @Jode on Workflows, we’ve received feedback for Workflows both around its strengths and improvement areas as well.

We will also be improving the documentation shown in your screenshot above for more clarity.

Reply


Terms & ConditionsCookie settings