Hi Guru's ,
I'm currently exploring AEM 6.3 forms and trying out a usecase to invoke a rest endpoint on click of a button .
I achieved this use case in AEM 6.2 via code editor where on click event I was excuting a peice of java script code which would make a ajax style call to rest API and render the response .
I'm trying to see if there is any better way to acheive this in AEM 6.3 .
I do not have the swagger file for the REST API and it is a third party service . Will i still be able to use Forms data integrations ? Or Is there any GuideUtils API to invoke rest based endpoints or java script way is the best to go ? I found the article below to execute SOAP based services , however couldn't find any thing similar for rest based calls ?
Thanks in advance
Here is a general AEM article on how to invoke a 3rd party Restful web service: Scott's Digital Community: Creating Adobe Experience Manager services that invoke third party Restfu...
You can write an AEM OSGi service that contains Java logic that sends a request and handles the response.
Being a consumer of third party rest api , dont have swagger file to create a Form data model.
HI Darren ,
Thanks .Yes i have tried my hands on the new Data integration .The forms data integration expects a swagger file for the REST endpoint to create a form data model .
Unfortunately I'm working on a third party service and they don't provide swagger endpoint for the API .
Is there any way in Forms data integration to create the data model with out swagger ?
I havent done it myself, but I get the feeling you can create a locally hosted Swagger file that defines the remote service. You have to write it yourself and host it locally but that should work.It would be good if Adobe can confirm this approach.
It raises the issue that your Swagger file might be out of sync with the remote service if they update their services at all, but any other method would have the same issue. At least this way its abstracted by the Swagger file, so no need to rewrite any code.
Thanks Darren .
Yes defnitely looks like one of the options.
On different lines though as you had mentioned , if the approach of swagger file is taken it would give super authors power to use it in forms and invoke it which is nice.
Yes totally agree - its a tradeoff depending on who will be authoring the forms.
Also be aware of a limitation currently in Data Integrations where you can't inspect the response messages from the server after a REST/SOAP/JDBC service call. You can't tell the difference if the server returns an empty result set or if an error has been thrown by the underlying service call using the UI. You just get no response object. I have identified this with Adobe and hopefully there will be a fix in a later feature pack to allow this use case.
Thanks for calling it out Darren and nice that you already raised it with Adobe .
Yes i noticed it when i was trying to integrate a SOAP based service. Had to dig in to server logs for error response but UI was returning empty response object.
>> On different lines though as you had mentioned , if the approach of swagger file is taken it would give super authors power to use it in forms and invoke it which is nice.
Data Integration support both approach i.e. either provide the URL where swagger file is hosted or you just upload the swagger file in configuration. Details about REST configuration are available in article section "Configure RESTful web services"
>> You can't tell the difference if the server returns an empty result set or if an error has been thrown by the underlying service call using the UI. You just get no response object. I have identified this with Adobe and hopefully there will be a fix in a later feature pack to allow this use case.
Yes, Currently test UI handles limited set of error cases but if service invocation is failing due to some reason complete details will be available in error log file.
>> Yes, Currently test UI handles limited set of error cases but if service invocation is failing due to some reason complete details will be available in error log file.
How do you tell the difference between an error and a zero result set when you publish the form into production? The end users won't have access to the error log file. They will just think their search returned zero results. You can't tell using any of the available form APIs either so you can't handle this programmatically.
This is not a small issue - it prevents the whole FDM being used in a real live environment until we can tell the difference.
Yes, Currently its very difficult to track if form submission or invoke service is failing and bug is logged for propagating error message from FDM to Forms and display in UI
Did you get any response from Adobe on the response from the service? We have started on forms now and we have similar requirements, could you please confirm on the outcome? Thanks
Ok so I thought I would update this thread since I have checked out AEM Forms 6.4 Form Data Models offering. While there has been a few updates on some features including Cloud Services Configurations and Computed Properties , unfortunately there still doesn't seem to be a solution for handling statuses generated by erroneous FDM calls. We still have no way to tell the user if a search returned zero results or has thrown an error.
Adobe did release some info in AEM 6.3 / 6.4 on the API to execute the data calls , but it doesn't include a way to handle the status returned by the API call. Bit of a shame because there has been so much effort put into this feature that is still (by all accounts) unuseable for anything other than demos.
It would be helpful if Adobe could explain why returning a service status is so far down on the backlog it never made it into this release?
Edit - I just found the ApiResponse Object in the DEFAULT_SCHEMA. Nothing found on how to use it so I'll have to figure it out
Edit 2 - Ok it seems this is provided by the Swagger PetStore test API and not AEM Forms. Doesn't seem to be useable - Adobe?
This is a worrying shortcoming of the solution. We're new to AEM Forms and REST integration will be essential and I really need to recognise success vs error responses and handle them appropriately.