Currently trying to work out how to use REST API to execute an action.
I added the ReverseInvoice action from Bills screen on my endpoints. And seems execute fine. Unfortunately, executing an action does not return a result e.g. 204 No Content. I'd wish to extract the RefNbr of the Debit Adj. raised.
Second problem is how do you stack actions or call series of actions ? The raised Debit Adj is not Released. So it seems ReverseInvoice & Release need to be executed at the same time. Plus, I also need them to be allocated against each other automatically.
I've got a feeling the REST API is not the way to go with this one.
Cheers and thanks for responses.
Unfortunately, you're correct on both points: Acumatica's Contract-based API (both SOAP and REST flavors) doesn't allow you to get the entity that is a result of an action (you can only get the status of action invocation), and if you want to chain a sequence of action you'll have to do that manually from the client (call one action, check for the status, call the second one, check, raise, rinse, repeat). Or you can write a customization with a custom action that call two actions in sequence, and call that from the API.
Related
We are using the following API call to get orders created in SC as unshipped orders.
https://sellingpartnerapi-na.amazon.com/orders/v0/orders?MarketplaceIds=ATVPDKIKX0DER&CreatedAfter=2021-01-01&OrderStatuses=Unshipped
Above one returns correct order data if there are no partially shipped orders. But, if there are partially shipped orders, the API call above includes that one as well. This is causing a problem while syncing the orders between SC and SAP.
The same thing is happening if we call the API with below url -
https://sellingpartnerapi-na.amazon.com/orders/v0/orders?MarketplaceIds=ATVPDKIKX0DER&CreatedAfter=2021-01-01&OrderStatuses=Partiallyshipped
is there a way to restrict the API call to return only either Unshipped or Partiallyshipped orders when called for a single Order status?
Github link - https://github.com/amzn/selling-partner-api-docs/blob/main/references/orders-api/ordersV0.md#orderstatus
Thanks
Sugata
I have a task to implement an Azure Function which is triggered by an HTTP-Webhook defined in Microsoft DevOps (VSTS).
The idea is as follows:
We have a backlog-structure (let's say: Epic > Feature > User Story > Task)
If i set the state of any of those items to 'Done', all underlying items should also change to 'Done'
What i have done so far
I have enabled a webhook in DevOps which triggers on update of any workitem and sends this item as JSON to an Azure Function
I have written the Azure Function which is invoked by an HTTP-request and get's the URL of the item which has triggered the request
The function then gets all items which are a child of the first workitem
The function patches all found child items with the state of the first item
All direct children are updated on DevOps
What i need
I'm trying to figure out an option to enable recursive update. Not only direct children should be updated, but also all their children (if they have some) and so on.
I thought about the following ways to accomplish this and need your guidance:
Get all direct children as JSON and then send HTTP-request's to the same function, passing all child item's
call the function within the function (don't even know if this works) and pass the children as JSON
find a way to handle all the logic in this single function (dumb foreach-nesting to ensure all backlog-hierarchy levels are processed)
If any code snippets are needed just tell me and i will provide the requested parts (right now i'm quite unsure what part of my code i should publish and would be helpful)
From your list of approaches:
Get all direct children as JSON and then send HTTP-request's to the
same function, passing all child item's
[Please see Fan-Out/Fan-In scenarios in Durable functions. This will achieve what you are looking for]
call the function within the function (don't even know if this works)
and pass the children as JSON
[This is not recommended. Please see here for best practices]
find a way to handle all the logic in this single function (dumb
foreach-nesting to ensure all backlog-hierarchy levels are processed)
[Same here. This is not recommended. In general it best practice to avoid long running functions]
I am using SS 1 and a Suitelet to load a list of associated assembly items and then, the user checks which ones to mod. I mod them but I am running up against that limitation of script usage. Well I offloaded this to a restlet and I did the user auth for the Authorization (username password) now I am getting an
"INVALID_HOST", "message" : "Invalid host debugger.sandbox.netsuite.c" message in the response from 'nlapiRequestURL' I am calling the script from a Suitelet, how can it be an invalid host? Any help would be great, thanks
Need more info to solve the Invalid Host issue, could be caused by something in the code as I noticed the url is incomplete, if you paste it I could be able to help you further.
Taking a step back to what you are actually trying to achieve you can proceed in two ways:
1: Process the user input immediately. (The user would have to wait until the process ends)
2: Schedule a batch job. (This is the recommended option for large operations)
If you decide to go with option 1(Process Immediately) then I suggest setting up a clientside function attached to a button on the form. Additionally you would need to accept POST request in your Suitelet to receive the data and process it. Your clientside function would process the items in a loop and would pass each item to the Suitelet for processing using ajax calls (Dont use nlapiRequestURL as it would use governance points). If you want to get fancy you can even add a callback function to your ajax call and display a progress bar so every time one of the records is processed by the Suitelet your progress bar would be updated and at 100% show as "Complete".
If you go for option 2 (Schedule a batch job) then you can pass the data as a parameter to a Scheduled Script using nlapiScheduleScript(scriptId, deployId, params), process the data in a loop and have it send an email to the user at the end. Preferably you would want to use a Map Reduce script but that's on SS 2.0.
The documentation (https://msdn.microsoft.com/en-us/office/office365/howto/sync-calendar-view) for getting a calendarview implies that the SeriesMaster event will be returned in the result, along with the individual occurrences and exceptions.
The documentation states (and shows by example):
Here's the information you need to know about how recurring events are handled for calendar view synchronization.
The service performs meeting expansion and sends the series master event and all of the event instances within the time window.
The series master event contains the recurrence pattern and the time window for the series.
The event instances contain their start and end time information as well as information about event occurrence exception.
However in actually using this endpoint, we're only receiving back the Occurrences/Exceptions and not the recurrence "master". The Occurences are full models, unlike slimmer models containing only the start/end like the documentation states.
It's important for us to be able to get sync SeriesMaster events along with the exceptions for the series (as is possible with GCal singleEvents=false) such that we can store this information and perform recurrence expansion on the client-side.
What am I doing wrong here?
Request (decoded for readability):
GET https://outlook.office365.com/api/v1.0/Users(...)/calendarview?$sort=startDateTime desc&$top=100&startDateTime=2016-01-01T22:12:34+0000&endDateTime=2016-03-10T23:12:34+0000
There is a similar issue when we try to get the CalendarView in EWS.
The Outlook calendar sync REST API works well as the description for me. Did the API works for you when you remove the $top query parameters?
Because the Outlook calendar sync REST API doesn't support $filter, $count, $select, $skip, $top, and $search query parameters.
Here is the link for the sync API for your reference:
https://msdn.microsoft.com/office/office365/api/calendar-rest-operations#Syncevents
Here is the response from calendar sync for your reference:
I build a plugin that runs in account update message that makes some validation not to duplicate the record. But if I try to disable that account or merge with another one it triggers the plugin.
How can I tell if the plugin was triggered by an activate/deactivate/merge action, or event mode like the one in CRM Dynamics 2011 Save Event Arguments Reference?
To add to Pete Oakey's answer, you can actually tell your plugin to fire only when certain fields are changed at the registration phase, in addition to testing this in actual code # runtime, by changing the "Filtering Attributes" of the plugin step. So unless your validation logic specifically needs the StateCode/StatusCode attributes to correctly process, you can filter those two attributes out, or just include the attributes your validation logic needs.
Original answer:
I believe you can reference the IExecutionContext.Depth Property of the IPluginExecutionContext object.
Every time a running plug-in or Workflow issues a message request to
the Web services that triggers another plug-in or Workflow to execute,
the Depth property of the execution context is increased. If the depth
property increments to its maximum value within the configured time
limit, the platform considers this behavior an infinite loop and
further plug-in or Workflow execution is aborted. The maximum depth
(8) and time limit (one hour) are configurable by the Microsoft
Dynamics CRM administrator.
So you can use an if statement to check if Depth > 1.
One way would be to compare the before and after values of what's changed on the account entity in the plugin. For example if you have only have active (if that's the right property name) in the values - you can look at the after value to see what's happened.
Another way would be to add a specific plugin for these messages and set some property/flag which you can check in the update plugin. Obviously this would have to run before the update plugin.