I have created an ACTION workflow, and it's synchronous as default, Can I change it to asynchronous and how?
Let me explain the options we have.
You can have a custom Action and that can be invoked from an Asynchronous workflow. Read more
You can register an Asynchronous plugin step to execute on this Custom Action message. Read more
Related
Is there an example of how to invoke an action from within an action?
All the hello world examples use the cli to invoke them. Where do I start when I want to programmatically invoke an action. Do we use the rest API and what would then be the api-host?
If you're using Node.js to implement the functions you can use https://www.npmjs.com/package/openwhisk. The REST API is documented here https://github.com/apache/openwhisk/blob/master/docs/rest_api.md.
In order to invoke ow action from another action, the "parent" action should be created/invoked with annotation provide-api-key == true.
E.g. if invoked using wsk:
wsk action invoke myaction -a provide-api-key true
Then OW populates the parent action with credentials required to communicate with OW.
https://github.com/apache/openwhisk/blob/master/docs/annotations.md#annotations-for-all-actions
Is it possible to add a CodeAction to the declarative .dialog file somehow? Or what is the current way of calling custom code from a trigger action?
There is no way to use code actions with declarative dialogs. You'll have export the runtime and follow these instructions: https://learn.microsoft.com/composer/how-to-add-custom-action
How to get an ajax request in the context of a class that extends from \Elementor\Widget_Base. The problem is that the widget is registered later on the "elementor/widgets/widgets_registered" hook, later on the hook responsible for registering ajax requests in wordpress.
Obviously, I can create a file in my plugin to connect it and process ajax requests in it, but I would like to implement this task within the widget class, how can I do this? I suspect there is a hook for this in the elementor, but I can't find it :)
I know it's not what you are looking for, but in my case changing "elementor/widgets/widgets_registered" to "init" hook solved that problem. Eventually init hook register widgets as well
I am working on designing a lengthy approval system in CRM using a combination of OOB workflows (designed using CRM UI Workflow Designer) and custom actions (actions written using .NET code). Idea is to keep the entire branching/simpler logic in OOB workflow and call custom Actions wherever necessary. However I have few questions with this approach:
How can I handle run-time errors generated in the action code?
For example, one of my Actions contain the code to push data to an external system via web service. In case this web service call fails, I need to perform some steps in the parent workflow.
How can I handle 'if conditions' which can't be handled by 'Check Condition' step? For example, suppose that before performing a certain workflow step I need to check some data which can't be queried within CRM. I can create an Action which will return true/false based on the custom logic which can then be checked in parent workflow.
An alternate approach would be to use plugins but I am inclined towards using OOB functionalities as much as possible. Any inputs would be helpful.
First of all let's clear the semantics, because I'm not sure if you understand what are you talking about - there are Actions (you can refer to them as custom actions, but then you should refer to every workflow you create as custom and I figured out of your post that you are describing them as OOB, which also is semantically wrong - every workflow you create is a custom workflow, maybe it's using OOB steps, but that's a different story) and Custom Workflow Activities. I'm assuming that you want to use Custom Workflow Activities, because the are more suited for what you are trying to achieve here. Also you tagged your question as CRM 2011 and CRM 2013 - not sure what you meant, because Actions were not available for CRM 2011.
So basically Custom Workflow Activities can have Input and Output parameters. Output parameters are answer to both your questions, because you can use them to get the error message after your custom processing or use then in conditional statements later in your workflow. Output parameters can be defined like that:
[Output("Error message")]
public OutArgument<string> ErrorMessage { get; set; }
You can find more examples here:
https://technet.microsoft.com/en-us/library/gg327842.aspx
You can of course set this properties simply by calling
ErrorMessage.Set(executionContext, messageText)
So now when you define your workflow, wherever you need something not configurable in OOB blocks, you can put your Custom block, after it's done simply check it's output for the error (this is just an example, you can pimp it up by adding additional output parameters, to make it more generic), if it's empty then do something, if not then do something else for example send email with the error message. It all depends on what are you trying to achieve.
Actions are serving different purposes, they are useful to create a logic that can be easily called through plugin or javascript (webAPI) and allows you to also put a plugin on it alongside doing everything within one transaction. Maybe it will be useful somewhere in your workflow, but as far as I remember in CRM 2013 actions could not be called from a workflow...
UPDATE:
Ok so if we are dealing with CRM 2016, we can call Action from a workflow. What is best in this situation really depends on the scenario and what we are trying to achieve, but to make it easier to decide let me highlight main differences:
1) Activities are simply a blocks of code that can be put inside your workflow. Actions by themself are not code, they are custom Messages that you can call. Of course you can register a plugin on this custom Message and do there any custom logic you want, but this is another step to take
2) Actions can be run in transaction, Activities not (but you can run Activities inside Actions, so in this case they can run in transaction)
3) Actions can be called directly from Javascript, plugins and workflows. It's a great thing, but if you will make let's say 10 custom Actions which you will be using ONLY inside you one workflow, they will be visible when you will be registering plugins (and also any js developer will be able to call them with JS)
So basically Actions are a big, fat feature that can serve many purposes (including running Activities on their own!), Activities are much simpler but in your case they will also do their job. So you should ask yourself questions:
Do I need my logic to run inside transaction?
And
Do I need to call this logic somewhere else than my workflow?
If you have any "Yes" then go for Actions, of no, then go for Activities, because you will be overcomplicating things without any good reason.
In the scaffolded module there are two alternatives of the actions defined: a window action and a server action.
But what is the difference of those actions conceptually and when to use which of them?
In Window action, we are register Tree,Form,Kanban,Calendar etc ids. Based on priority, it will open related view.
While Server action are useful for following different-different purpose with selected Base model.
Send Email
Execute Python Code
Trigger a Workflow signal
Run client action
Create or Copy a new Record
Write a Record
Execute several actions