Hi Mathias, Thank you for your response, its greatly appreciated. After posting this topic I was able to resolve the issue which subsequently fixed the below API patch requests;DocReferenceObjectAttachmentHandling.svcMediaLibraryAttachmentHandling.svc I was able to complete the patch request similar to your instructions;x-ifs-content-disposition - Filename encoded to Base64 (used base64encode.org to get the result)If-Match - eTag set following the format demonstrated in the video.but the requirement for the ‘xsrf’ token was not needed for either usage. A worth mention note, when using a GET request (POSTMAN) to retrieve all entries. The JSON object returns additional characters that needed removing (See example below).W/"Vy8iQUFBU0o5QUJFQUFBemhVQUFBOjIwMjIwMjAxMTUxNjQ1Ig==" - is the correct entry for use in the If-Match parameter box.Postman Header Variables Using POSTMAN, providing the above parameters are set for the header request.Attaching a document (valid filetypes for individual
The documentation was useful to piece together header variables and get the correct URI path but there is no additional instructions anywhere on IFS which helps users or developers understand the processes that Aurena uses to complete it’s action ‘under the hood’ so to speak. At this moment in time, the PowerApp I am creating will still not complete the PATCH request when updating Media Items but I suspect this is due to encoding and conversion issues within the application and the stream becoming to long to pass with the request. Does Docman only use octet-stream (binary) as an upload type? or is it possible to upload base64 encoded text as part of the PATCH request? If so, could you provide an example of where the base64 string would be inserted as part of the body request?See below{ "Name": "It is a Text", "Description": "It is a Text", "MediaObject": "", "MediaText": "", "MediaThumb": "", "Obsolete": "It is a Text", "Resolution": "It is a Text", "MediaFile": "It is a Text",
Hi Again Mathias, So, I have tried to complete a flow using the PATCH request for the MediaAttachmentHandling.svcAttributes are dynamically added, and im pretty sure its just the raw data causing the internal server error but cannot be 100% certain as its running in PowerApps so fiddler cannot see the flow requests! I have attached a snippet from my flow which uses PowerApps Pen Input.PenInput encoded to JSON object,24 Characters stripped from beginning and end of base64 encoded string so only the raw binary data remains.Then converted via ‘base64tobinary’ function. Any possible recommendations? Thanks in advance, Kind regards, Brian
Something ive found is when you log into the IFS cloud environment via web browser.Credentials entered are submitted to an authenticate path and a html is returned containing a redirect to the internal IFS cloud system.The html returned from the auth url states a 302 response “found” which could be handled to allow progression in your application to a different screen. I am currently working on this process within power apps and using an Iframe component + flow to handle a 302 response and navigate to another screen within the power app. There could be a similar process when using aurena for apps 10, i haven’t tested this as of yet. Hope this guides you, Kind regards, Brian
The PATCH request requires the MediaItem’s ID to be able to attach the binary image to it, The MediaItem when created is referenced to a key reference (my project is using ORDER_NO={x})See working postman request below;The process used for this project follows a step by step tutorial for creating .jpg images using PenInput in power apps I have tested the json object in a base 64 to image online converter and it displays correctly.Using the video’s development process, created the image in one drive and downloaded it my device.used that same image via the postman request (and it worked without issue!) Im currently looking at using the document attachement handling .svc to see if the problem is only with the media attachment .svc and will feedback on the results, thank you for your help and guidance so far Mathias! Kind regards, Brian
Hi Mathias, Update on the situation, embarrased but successful…. The ‘==’ on the 64encoded file name where added via a concat statement in the power flow. Suggestion to any user exploring the same topic..Check encoding of filename - does not need == to be deemed encoded (bad demonstration by youtube) Removed them and all is good. Thanks for your help Kind regards, Brian
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
