![]() An example of such a case is when a user is attempting to delete a task but that task already has dependencies like Actuals created against it. If the asynchronous operation persisting changes fails, changes made in the UI won’t be written to Dataverse and the user sees the data roll back in the P4W UI. It goes to PSS, which then accepts and persists it to Dataverse. In other words when a user makes a change to, for example a task’s start date, data is not directly written to Dataverse. When a user changes values in the P4W UI for columns like task start/end, duration or effort, the P4W UI talks to PSS in Azure. ![]() Those of you who have experience in Dataverse know that it can be a bit slow and it doesn’t offer co-authoring like we’re all used to from tools like Word, Excel, and Power Point. As P4W is build on the Power Platform i.e it runs on Dataverse, PSS is a means of enabling a fast experience with co-authoring capabilities. The scheduling engine of P4W, the Project Scheduling Service (later PSS), is hosted in Azure. The reason for that is in the overall architecture of Project for the web, which is the infused project management and project planning experience in Dynamics 365 Project Operations. You might be wondering why new, specific APIs are needed to CUD the aforementioned tables. They’re used to programmatically create, update, and delete what are known as scheduling tables. ![]() Schedule APIs were introduced to public preview in the spring of 2021 for Dynamics 365 Project Operations and Project for the web (later P4W). Tested on Project Operations on Dataverse version 4.11.0.156 (June 2021 update)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |