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.
Related
I am trying to get and set the forwarded/replied state of an email message in the Graph API. This is the represented in OWA by the little icon in the right column.
It seems there is not a first class way to access this information, at least it does not come out in the unfiltered JSON dump.
Google suggests this is stored in the extended properties for PidTagLastVerbExecuted or PidTagIconIndex, however attempts to access these just give back 404:
https://graph.microsoft.com/beta/me/mailFolders/{id}/messages?$select=SingleValueExtendedProperties&$expand=SingleValueExtendedProperties($filter%3Did+eq+'String+0x1081')
Other extended properties like 0x0070 do work, so it seems the syntax is correct, and 0x1081 comes from here https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtaglastverbexecuted-canonical-property
This information is stored, you can see it in OWA, the Outlook apps, and you can see it in IMAP.
Is there some way to do this? It seems strange this basic information about the email state is not made available.
Your specifying the wrong datatype that property is defined as a Long in the documentation (but the doco is for MAPI) so its actually an Integer in EWS and Graph eg this is something i used to return both PidTagLastVerbExecuted and PidTagLastVerbExecutedTime (which gives you the time of the last action)for a particular message
/v1.0/users('user#domaincom')/MailFolders/AllItems/messages/?$select=ReceivedDateTime,Sender,Subject,IsRead,inferenceClassification,InternetMessageId,parentFolderId,hasAttachments,webLink,InternetMessageHeaders&$Top=1000&$filter=internetMessageId+eq+%27%3cSG2PR04MB3223962312D5B46D0C9CA1B5C89C0%40SG2PR04MB3223.apcprd04.prod.outlook.com%3e%27&$expand=SingleValueExtendedProperties($filter=(Id%20eq%20'Integer%200x1081')%20or%20(Id%20eq%20'SystemTime%200x1082'))
Please expand your NgxsFormPluginModule description on gitbook.
I just implemented a reactive forms example with #ngxs/form-plugin.
It works great, but it was a bit of a struggle to get it to work; because it was not clear to me that the form state must have these specific properties:
model: YourFormModel,
dirty: boolean,
status: string,
errors: {}
Maybe you could add an explanation of these properties and their intended use?
What are the possible values for status, or is this up to the developer to define?
What type of object is errors and what is it used for? It appears to be empty even when validation fails. errors would suggest it is an array, but the example defines the default as an object?
I am posting this as a question because of your answer here: Where is it best to post questions about ngxs?
status field is supposed to store latest status of FormGroup.
You can see the code that is responsible for its update here.
The possible values for status are defined here.
errors is supposed to contain validation errors for the whole form group.
Its type is ValidationErrors since it's supposed to copy errors from the corresponding form group.
The code responsible for its update is supposedly here.
But there's an unsolved issue with filling it with actual error data., so it's not available yet and you'll have to rely on controls' error data.
I'm recording statements to the LRS and in each of those statements I always set the "Team" property.
I know I'm able to filter those statements by verb, activity and many other parameters as described here.
However, I can't find a way to filter statements by Team (which is a property of Context).
Is it possible?
I think the best you can do is to use identified groups (a group with an IFI) as the value of the "team" property and then request statements using the "related_agents" query parameter. Note that this will include statements where that identified group is also the "actor" or in any of the other positions accepting a Group/Agent object, so you'll still have to post process them. As far as I know there is no way to request based on an unidentified group since they aren't considered the same group across requests.
There is no way to specifically request only statements based solely on the "context.team" property.
I am assuming that you have added team property to context.extension property. You should not add properties that are not allowed, otherwise, you might have issues in future.
Regarding querying by team or any other extension property, it cannot be done as per standard xAPI Spec. However, your LRS could allow you to do that. e.g. You can get an LRS like GrassBlade LRS or Learning Locker and get it customised to add more filtering options.
On the saving of Case record I want to assign the case to respective Agent based on case type , sub type and Client/Account,
I have a Assignee field on Account form which I need to get the Agent's name to Assign the case.
I am creating a custom workflow activity for that, but while writing it I stuck how to fetch Case forms record on which I apply logic.
Please suggest what is the good approach, do I need to make a retrieve call to fetch these parameters or something else.
While setting the Custom Step Input Properties drop down fields are not populating to select the Dynamics Values.
Better to use plugin, as the documented/supported preimage is available in plugin steps + flexible.
You have to look for type, subtype, etc in target entity (incident in your case) or preimage if needed to apply logic.
If you still want to use workflow, go ahead & follow this article.
we can always read Pre image and Post image in the plug-in for various purpose. However, in workflow, we may sometimes want to read Pre Image for some purpose. Now we can also read Pre Images and Post Images in the workflow using Execution Context. It uses the same Plug-in Architecture and hence we can use it to read Pre Images and Post Images. However, this concept is not documented in the SDK so it might be unsupported.
when getting back references from Yammer through the dev api, they can be of a few different types. Is there any documentation somewhere that describes the JSON model of returned objects?
Right now I have got the following from just reading the returned JSON.
Type:
- "user"
- "guide"
- "group"
- "thread"
- "topic"
But there could be other types I'm not expecting which could be sent in the future. Is there a list somewhere that describes indepth all the possible return types from the Yammer API?
There's not currently any documentation resource that will provide that information. It's also possible for additional reference types to be added later.
To deal with references robustly, you'll need to add code to handle the reference types you know about and do something reasonable for reference types you don't recognize.
The something reasonable may vary, but a good start would be to somehow log the reference and otherwise ignore it.