@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.

We are facing huge issue in worklows when will be depreciated ? In wich version of IFS Cloud

I agree with the issues. I do not find Workflows stable. I recently tried a Workflow to replace a standard command button where the standard function does not behave the way we want (PM Action generation from PM Program), but it timed out and just hung somewhere in the background, while locking tables until the session was killed from the backend. That exposed what to me is a huge problem: you can configure Workflows from the UI, but not monitor them. I had no way of stopping that workflow (like you for instance can stop a background job). They might be good for popping up a dialog for the user to enter something and then save that somewhere using a projection call, but that’s about it.

As for the error exporting event actions, the PL/SQL block itself is stored in the ACTION_PARAMETERS column, which is a CLOB, so that’s not the problem. I’m tipping the bug can be found in Fnd_Event_Action_API.Export_XML, where a simple select statement is used to fetch the data to go into the XML. I guess something in there does an implicit type conversion from CLOB to VARCHAR2. Perhaps this line:

                                  e.action_parameters ||  NVL2(Fnd_Event_Action_API.Contain_New_Line(e.action_parameters),'''','''||CHR(10)||''') || NVL2(pro.is_template, ''$IS_TEMPLATE=''||pro.is_template, NULL) action_parameters,

Or this one:

   ctx_ := Dbms_Xmlgen.newContext(stmt_);

On the other hand, I don’t line Online SQL event actions because I know how to wreak absolute havoc with them. A way to avoid some of the possible data corruption issues with them would be if they ran under a different user schema, say IFSSYS instead of IFSAPP, so they wouldn’t have write access to tables.

​@AussieAnders ,

I have found a similar issue regarding the workflow locking entire tables which we use for our technicians app as well, causing an entire department to shut down multiple times.

The cause for the workflow to freeze is unknown, it really seems to be at random. But I can't kill or monitor it myself and I have to create a support ticket only for them to say they can't do anything about it.