Writing back to Fusion

Creating and updating, THE VALIDATION THAT HAPPENS ON THEIR SIDE, and READING A FUSION ERROR INTO SOMETHING A USER CAN ACT ON. Reading is forgiving. Writing is where an application meets the rules of a real business system, and those rules are not yours and are not documented in your page. THE MECHANICS ARE THE EASY PART: A POST OR A PATCH, A BODY, AND A RESPONSE. A PATCH sends only what changed, which matters more than it sounds — sending the whole record back is how you overwrite a field somebody else edited while your user had the form open. THE VALIDATION IS THE POINT, AND IT IS FUSION'S RATHER THAN YOURS. Required attributes, valid combinations, business rules configured by somebody in another team, security preventing this user from touching this record. Your page cannot know most of that, and it will find out by being refused. SO EVERY…

In this module: Module 6 · Connecting to Fusion

1. 1What a service connection is
2. 2Creating one against a Fusion REST APIFree preview
3. 3Authentication, and whose identity is used
4. 4Why a shared service account is usually wrong
5. 5Query parameters, filtering and fields
6. 6Pagination, properly
7. 7Writing back to Fusion
8. 8When the shape changes underneath you
9. 9Calling an OIC integration instead
10. 10Handling a service that is down
11. 11CORS and the errors it produces
12. 12What breaks: four connection failures
13. 13Lab briefing · Connect, over-fetch, then fix it