Power Automate: Run a child flow by GUID - power-automate

I'm trying to call a child flow from a Power Automate flow by it's guid (by using an Expression in the Child Flow dropdown), instead of hardcoding the child flow selection.
However, whenever I try to save the parent flow, I get the following error:
Request to XRM API failed with error: 'Message: Flow client error returned with status code "BadRequest" and details "{"error":{"code":"ChildFlowIdNotValid","message":"The workflow id '[[expression]]' is not a valid child flow id. The id must be a valid GUID."}}". Code: 0x80060467
I tried various expression, even simple stuff like #guid() (which is definitely a valid guid), but to no avail.
It seems like the platform performs a "compile time" check on the value, which makes using any dynamic value impossible.
Any ideas?

I think that Run Child flow action is designed to be more interactive than programmable, unfortunately. Interacting with the Run Child Flow action calls an API, and the response is used to modify the action definition. Whatever is the "custom value" expression - it is not evaluated, but instead read as string, and used in a call to retrieve the sample header. That sample is then used to re-format the Run Child Flow action to show the appropriate headers.
Having an undetermined target would mean the call body is not defined, which could be a problem. Interestingly, it does pop a spot for a body when initially trying to look for a hard-coded GUID.
You can see the after-effect of this behavior in how even hardcoded GUIDs get replaced with the flow names once saved/reopened.
As a workaround, I stack Run Child flows in a Switch action checking an expression result. I.e.:
Switch workaround
Side note - GUID() in Azure Logic Apps (and powerautomate) does not format an arbitrary string as GUID.

Related

How to get the result of a asynchronous action in NGXS?

I want to perform an action based to the result of an asynchronous NGXS action.
In a Angular frontend app I'm using NGXS for state management. Some of the actions involve talking to a backend via REST calls. Those actions are implemented as asynchronous actions, with the reducer functions in my state classes returning an Observable.
What I'm looking for is a way to get hands on the result of the backend call, to be able to perform some action.
One use case I'm trying to implement is navigation to just created objects: Business objects are created in the frontend (Angular) app with a couple of domain properties. They get persisted in the backend, and as a result an ID for this object is created and returned to the frontend, and incorporated into the NGXS store. As a direct response to this, I'd like to navigate to a detail view for the new object. To do so, I need
(a) the information that the call has been returned successful, and
(b) the answer from the backend (the ID in this case).
Another slightly more complicated use case is the assignment of a number of tags to an business object. The tags are entities by themselfes, and have an ID each. In the UI, the user can either pick existing or add new tags. Either way, multiple tags can be added in a single step in the UI, which means I have to
call the backend for each new tag to create the ID
after all missing tags are created, update the business object with the list of tag IDs
In general, there are use cases in the frontend that depend on the result of a backend call, and there is no clean way to find this result in the store (although it's in there)
I know I can subscribe to the Observable returned from the store's dispatch method (as shown in asynchronous actions).
I also know about action handlers. In both cases I can attach code to the event of an action finished, but neither option enables me to get the result of the backend call. In the fist case, the Observable carries the whole store, while in the latter case I get the original Action, which is unfortunately missing the essential information (the ID).
The part you're missing here are selectors. Dispatching actions is not supposed to give you back a result. The only purpose of the Observable returned by store.dispatch() is to tell you when the action's handlers are done.
To get to the data returned by your calls to the backend, you have to patch the state inside your action handler. And then, outside of your state, you can access the data using store.select() or store.selectSnapshot() depending on what you need. Your state class should look somewhat like this (untested):
#State()
export class SampleState {
#Selector(SampleState)
sampleSelector(state) {
return state.sampleObject;
}
#Action(SampleAction)
sampleAction(ctx: StateContext<any>, action: sampleAction) {
return sampleBackendCall(/* ... */).pipe(
tap((result) => {
ctx.patchState({ sampleObject: result });
})
);
}
}
Now you can access this result where ever you need using the Store. For the use case of navigating to an element after its creation, you can combine a subscription to store.dispatch() with a store.selectSnapshot() like this:
store.dispatch(new SampleAction()).subscribe(() => {
navigateTo(store.selectSnapshot(SampleState.sampleSelector));
});
Note that in this easy case a selectSnapshot is perfectly fine, as we only want to get the value we just finished writing into the state. In most cases though, you will want to use store.select() or the #Select() decorator because they return Observables which enable you to also correctly display changes in your state.
That said, I'd like to add that if saving data inside the state is not necessary for you at all, then probably NGXS is the wrong library for you in the first place and you could as well just use an ordinary angular service directly returning the result of the backend call, like suggested in the comments.

SoapUI (non pro) Property Transfer getting the basics going using XPath

Preamble: First off - I am a complete novice, and have zero clue what I am doing, apologies in advance.
Question:
I have working SOAP messages in SoapUI (regular flavour) that I have valid responses to. I am trying to build a set of test steps that can complete a transaction lifecycle for testing.
I only just figured out that Property Transfer could be used to take a response from call A to be used in call B.
I have the source declared correctly, and the Target correctly, With the default namespace info I have successfully transferred the complete response of call A into the target property. Now I just need to cut that down to one element only. I have tried all manner of things, but I seem to be getting [null] every time (except where I don't include the bit to choose one element at all, as noted above).
I just don't know what the format of the line that specifies the desired field should be. I know I have to have the name of the desired field in it, near the end, but beyond that I am randomly trying all sorts.
Okay, I have it solved, after many stupid trials and errors. For posterity and so I can reference it myself in future, this is what I got going:
Inside the soap message response body, there is a tag ns1 (which I am guessing is namespace 1).
Inside that is a section called salesInvoiceReturn.
Inside that is another section called salesInvoiceDetails.
Inside that is a field that I need is called salesInvoiceSalesTax.
So my line in the XPath Source section that works reads:
//ns1:salesInvoiceReturn/salesInvoiceDetails/salesInvoiceSalesTax
Pressing the Run button shows me it captures the correct value into the Custom Property I selected. I don't seem to need any code at all in the Target section.

How to know what InputParameters values are possible in Dynamics CRM Plugin context?

I'm trying to understand the plug-in sample from here.
There's this condition:
// The InputParameters collection contains all the data passed in the message request.
if (context.InputParameters.Contains("Target") &&
context.InputParameters["Target"] is Entity)
Speaking generally, not just with regard to this sample, on what prior knowledge should I base my decision to access a specific property? How could I have known to test whether the InputParameters contains a "Target" key (I assume I'm not supposed to guess it)?
And on what basis could I have known to ask whether the "Target" mapped value is of Entity type, and not some other type?
I found this post from 2 years ago, and I've found this webpage, saying (emphasis is mine):
Within a plugin, the values in context.InputParameters and
context.OutputParameters depend on the message and the stage that you
register the plugin on. For example, "Target" is present in
InputParameters for the Create and Update messages, but not the
SetState message. Also, OutputParameters only exist in a Post stage,
and not in a Pre stage. There is no single source of documentation
that provides the complete set of InputParameters and OutputParameters
by message and stage.
From my searchings, a single source still doesn't exist, but maybe the possible values can be found using the Dynamics Online platform, somewhere deep down the Settings menu, maybe? Any source would be great.
I know this is an "old" question that already has been answered, but I think this can be helpful. I've built a small web page that contains all the messages with all the Input/Output parameters. You can access it from here:
The best practice for doing this is to use a strongly typed approach. If, for example, you want to know which propertes are available on a CreateRequest, you would do:
var createReq = new CreateRequest() { Parameters = context.InputParameters };
createReq.Target; // Has type Entity
Take a look at the full blog post explaining this approach: Tip: Proper handling of Plugin InputParameters
Original answer:
It depends on which request we are talking about. See Understand the data context passed to a plug-in on MSDN.
As an example, take a look at CreateRequest. One property of
CreateRequest is named Target, which is of type Entity. This is the
entity currently being operated upon by the platform. To access the
data of the entity you would use the name “Target” as the key in the
input parameter collection. You also need to cast the returned
instance.
Note that not all requests contain a Target property that is of type
Entity, so you have to look at each request or response. For example,
DeleteRequest has a Target property, but its type is EntityReference.
In summary: Look at the actual request, e.g the CreateRequest.
In 2011 someone actually generated typed properties based on the message type. Kind of neat: https://xrmpalmer.wordpress.com/2013/05/27/crm2011-plugin-inputparameter-and-outputparameter-helper/
It would show you want parameters are possible per message.

jmeter how to replay recorded unique id from application

I am very new to Jmeter and trying to use it for doing load testing my application.
In my application, every time we click on a template, application will allocate a unique id which to the template...when I recorded the steps using jmeter, a particular unique id was recorded...but when I tried to play the recorded case...it is looking for the same unique id....how do I tell jmeter to get the new id from the application?
Here are the steps
Login as a user,
click on a particular link,
click on a button which will then popup a window asking to select a template,
After selecting a template, my application will create a unique id for that template
It very much depends on whether that template ID is created on the client (i.e. by JavaScript), or on the server (i.e. you can actually record a template ID returned by the server).
If second is your case, then server returns template ID in the response to template selection, so you can use one of the post-processors - a supporting element invoked after the parent request; it usually extracts data from the response and saves it as a variable(s). In your case you'd extract template ID and save it as variable. Later samplers can use the variable in format ${your_name} instead of the recorded hard-coded string. So in that case your plan could look like this:
Which post-processor to use and how to use it depends on the response you are receiving form the server, so cannot be more specific here.
If the first option is your case (JavaScript on the client generates template ID; and your recording only contains usage of said ID), then you can simulate what JavaScript is doing by generating a similar ID using one of the JMeter script-related features: it could be random function, an inline piece of JavaScript code, a scriptable sampler, such as JSR223 Sampler, or... There are many options really, depending on concrete needs of that generated template ID. Again, a more specific question would help to narrow down your choices.
Classic "correlation" example.
Look for that generated ID in the previous responses (you can do it with the View Results Tree listener)
Once you detect it you need to extract it and convert into a JMeter Variable with a PostProcessor (the most commonly used is Regular Expression Extractor, however depending on the nature of your request you may consider to use others
Once you get the ID extracted and stored in the variable - substitute hard-coded value obtained via recording with the JMeter Variable
Repeat steps 1-3 for any other dynamic parameters or values. Or, consider a faster way of creating a JMeter test via alternative recording solution which performs the above steps automatically so you won't have to worry about detecting and handling dynamic elements. See How to Cut Your JMeter Scripting Time by 80% article for details.
You need to check response of the previous request. Normally ID will be created and can be found in the response of previous request and you can use that ID for next request.
You need to first find in which response the ID is being generated and the format of the ID. You can use firebug to see the response in HTML format and find where the id is.
Once you have the format of the id, create regular expression around it. Test it using regex tester that comes with JMeter. Or you can use rubular.com to check the correctness of your regex.
Once you have correct regex, use regular expression postprocessor on the request which returns the id and then use that variable in actual request that uses unique id.

WebObjects field validation

I'm trying to find a good way to do field validation in a WebObjects app. If I have a text field and I tie a number formatter to it, it seems that the default behavior is to parse out the number IF the user enters in a valid number, or, if the user enters an invalid number, it seems to just ignore the value entered by the user. I can't do the validation in a save method or an action method because WO will have already ignored the non-number input by the time it reaches the action method. Is there a standard/recommended way, in a WebObjects app, of validating user input such that the user can be alerted of invalid input, rather than just ignoring the invalid input?
This page: http://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Validation claims that WO and EOF have "an incredible array of validation mechanisms" and even hints that there is a built-in way to prevent the user from entering inappropriate data, but I haven't been able to find any documentation or examples of how to do that (if there is, in fact, a built-in way). Coming up with a custom javascript validator to prevent inappropriate data seems like it would be a nightmare - finding a way to make the JS recognize and handle all of the same edge cases that the backend formatters/parsers handle. It would be nice if WO really did have a built-in way to propagate the formatter edge cases over to JS validation.
The above link also says there is a validationFailedWithException method in WOComponent that gets called "when an EO or formatter failed validation during an assignment", but how can I make a formatter fail validation in the non-number example case above? I've tried having the formatter throw an exception in the parse method if a non-number is entered, but that exception doesn't get passed to the validationFailedWithException method. Does anyone know how I can trigger an exception in a formatter that will trigger a call to validationFailedWithException()? And is that even the best/recommended way? Does anyone know of a better way?
I'm pretty sure, that validationFailedWithException is getting called for every formatting error. You should receive there an NSValidationException that wraps a ParseException. The method is usually called on the component containing the binding. It may get skipped on caret (^) bindings.
All the standard number formatter already throw a ParseException (see Format.parse(String)).
The validation handling in WebObjects can get quite complex, it really depends on your needs. But it was designed without JavaScript or Ajax in mind. Newer approaches in Wonder may incorporate the client side, but I have no experience with it.
The normal validation sequence is:
if needed convert the input into the target type with a formatter
call a validateAttributeName method on the target object, where AttributeName is the attribute name to receive the value
When something fails in this sequence validationFailedWithException is called.
While saving an enterprise object "validateFor..." is called on the objects. An exception at this point has to be caught in your action method.
So you have two points to handle validation errors. The "syntactical" errors have to be handled in validationFailedWithException. After this point you have valid inputs. You may manually further check those or greater object structures in your action method or in validateFor... (e.g. validateForSave).

Resources