@ShawnBerk  Thanks for your reply !

Are you saying that there is logic built in by the business where say, if you call (completely random example) customer_order_api.new__ (to create a customer order) within a PLSQL Codeblock, rather than a Projection CRUD Create Operation, and if that codeblock is originally called as part of a custom action set to a completely different projection and triggered through an event workflow, the actual insert might fail ?

I’d have thought that at the point you reach the PLSQL Codeblock, you’re “free” from the constraints of projections at that point, you just use the underlying PLSQL Package Methods and completely disregard any projection action (obviously this requires knowledge of the underlying schemas etc.)

Is that not possible?

Like I said, that is my recollection the last time I took a deep dive into the problem.  I would have to get the developer to dig back into this and confirm that is still true with a newer version (that maybe we’ve not installed).  What version are you testing with?

Recall I mentioned we are actually spinning our wheels on the entire project, not just this one bit of function.  There are major issues with the entire sales module that cannot be replicated in Cloud and functionality that is never planned, Service is miles away from where we’re coming from which is currently the Astea service product.  Engineering is an entirely new module for Cloud for us and doesn’t hold the same rigid Revision control that we’ve used in our existing PLM system.  It goes on and on, even if the BPA workflows have crept forward and you’ve found that it is possible to get further than before, the number of blockers is still prohibitive for us.

@ShawnBerk Currently testing within 23R2 I believe.

Completely agree with you that there are some other drawbacks present, as we discussed, such as Advanced SQL Searches being gone, or the other changes you mentioned :)

I’m just trying to make sure I have some sort of path forward with specifically event actions and that I know all the very real limitations that might exist so that I can report accurately to company leadership and offer recommendations for moving forward (or not)

Since i stumbled upon this i want to chip in from a consulting point of view. I used to work for IFS and now work for Novacura. We have our lown low-code tool that is native in the IFS world, so it's interesting to see IFS coming up with a workflow tool integrated in IFS.

IFS Workflow is certainly a nice addition to IFS overall, but in areas still a bit immature. It is not and will not be able to ever replace the full flexibility of PL/SQL events. I would still consider it a valid approach in terms of the Evergreen approach. If you are a heavy user of PL/SQL events it will be a challenge to keep a large amount of these up-to-date with frequent IFS updates/changes. I think there is a lot of potential for IFS Workflows still and it will be interesting to see how much IFS is willing to invest into it.
One thing to consider is, that even Workflow solutions will have the need to be kept up to date after upgrades. With every update IFS releases a list of "Breaking Changes" with IFS projections that have had a change that would "break" existing projection calls (e.g. a new mandatory input field). So while the upkeep is less than pl/sql code it certainly is not null. For our IFS connector (in our Low-code tool Flow) we plan to built in an automastic diff check which will mark all changed projections we are using. A feature like this would definetely be helpfull for workflows.
If you want to extensivly built upon/around the existing IFS functionality this will come with increased upkeep cost in the future as the number of system updates increases.

One of the biggest upsides of IFS Workflows is that we can finally configure dialogues and even full workflows. Why we can't select LOVs from IFS in Fields there is beyond me though. We have to write our own custom enummerations IN THE WORKFLOW and cannot even add translations there. If i am missing something here please let me know.
It's not possible to use variables in workflow responses which means you can only return custom static error messages e.g. "There has been an error". Fortunatly there is a workwaround for this one, although it needs a bit of setup.  
REST Calls have to be configured in the workflow. It's not possible to use e.g. routing rules unless you configure get functions in the workflow to fetch the address for one. No application message will be generated to keep track of messages/responses...

There are plenty of more things which lead to my "still a bit immature" comment up above. A lot of theses features should not be hard to implement.

My overall summary for IFS workflow would be:

- You CAN probably replace a significant number of existing events with it
- It works fine for simple automatisations
- Starting with workflows can be very frustrating. I would not describe the tool as intuitive.
- If you  are good in PL/SQL setting up a workflow will take significantly longer than a PL/SQL event in most scenarios.
- As soon as it gets a bit more complex you need a bunch of workarounds (e.g. custom Quick Report ->  Projection for more complex queries involving joins) to make it work. IF you can make it work at all.
- The Option to have input into custom buttons and built guided workflows in IFS is gold

For us it's mostly a good addition, BUT that's including our own tool Novacura Flow in the equation. We finally have the option to deeper integrate with IFS via Button/Event AND give direct user feedback/stop the process.
We usually go by:
- If it's simple try to solve it with workflow
- If it gets more complex do a Rest Call and let Flow handle the rest. We just have A LOT more options and flexibility in Flow, development is a lot faster AND our newest version of the IFS connector will also start to automatically check for differences in projections after an upgrade and point out these.

We are all still making our experiences with Workflows. There is a lot of potential and it remains to be seen what IFS makes out of it.  

​@ashdlk We are currently planning to upgrade our IFS 10 UPD22 version to IFS Cloud.

We are planning to migrate the existing ‘Execute Online SQL’ type event actions to IFS Cloud version too,

Any new requirements will be handled using Workflows, etc.

We would like to know whether the "Execute Online SQL" event type has been obsoleted in 24R2 or is there any plan to obsolete in 25R1 or 25R2 versions?

Your input is highly appreciated in planning the upgrade.

​@VPPEKANATHI  Execute Online SQL event actions have been Obsoleted for a while, they just haven’t been removed (yet). I think IFS is wary of actually removing the feature as a lot of customers have come to heavily rely on them in their configurations/customizations.

To be honest, and unless you have specific use case scenarios where a workflow is simply better suited, if you have someone who is good enough at PLSQL that they can use Execute Online Action without trouble, it’s probably much easier to retrofit the need as Modifications through Studio Developper using @Override and @Overtake of the PLSQL Methods to achieve what the business requirement is.

Studio Developper mods done that way also have the benefit of not being called through via Oracle Triggers (which Events are) which gives you some benefits such being able to query the same table that’d be getting modified without encountering mutating table errors etc.

​@SimonTestard  

Thanks for the reply. 

Given the tight upgrade schedule, we plan to continue using the existing Execute Online SQL event actions in the IFS Cloud version. We intend to replace these actions with workflows or customizations after the upgrade go-live and before IFS removes Execute Online SQL event type.

Do you foresee any risks with this approach?

I can’t see any issue with this approach, if/when IFS decides to ACTUALLY remove Online SQL actions (for good), this will be announced in deprecation logs for upcoming updates.

For instance, this hasn’t been announced on the deprecation log for 25R1 so it’s not been removed from that particular release update, but you need to keep an eye on those.

The day, if it happens, that it actuallys gets marked as removed, you want to make sure your retrofit all your Online SQL actions (to either workflows or SD Customizations) BEFORE you apply the update that its slated to be removed on.

​@SimonTestard  Thank you for your valuable input. Much appreciated.