How do I handle and return a human readable error in a Java Azure Function app? - error-handling

How do I handle and return a human readable error in a Java Azure Function app?
All examples of this on a Google search, are just simple instructions on how to do a try-catch, which is not my question.
More specfically, how do we design the return status code and the response body of the request, in a way that provides the most flexibility to a wide array of situations?
Given that we are not integrating Spring-Boot in this case, and that we do not have access to anything Spring.
Given that my API generally returns an object that we will call Pojo1, on error, what is the best way to return a informative message.
NOTE: Of course, I do know there are situations where you want security through obscurity, in which case I would probably choose logging errors to app insights. This is not my question though.

Well, you can set custom headers while returning the request. This
can be done using a setHeader function.
You can also use azure service bus or event grid which will carry
specific messages regarding the errors.
Also, you can use azure monitoring which collect all the error and
notify you when everything happens.
Refer this article by Eugen Paraschiv for indepth explanation on how to use setheader.
Refer this documentation on azure service bus and this documentation on event grid.
Refer this documentation on azure monitoring logs.

Related

How to handle errors when making a call to app insights?

My web app is integrated with App Insights for telemetry purposes.
My question is this:
If I have my app insights configured incorrectly, i will get an error.
Should this error break the UI, or gracefully let the user know of the error, or should it just be silent/ignore it?
thanks.
It will depend on the type of application, end users etc.
Type of application - If this is going to be a public facing application, I don't think you would want the end users to know that there was an error with instrumentation. A regular check of the data being collected could help you understand if AppInsights is not configured correctly.
End users - If the end users are internal to your organization/team, the error information on UI could be considered for faster diagnosis.
Depending on the Framework/platform being used for the application, you could enable it using Auto-Instrumentaion which does not require a lot of configuration update to enable AppInsights. The chance of error here would be minimal.
However, if you are going with the SDK method, you could check the AppInsights logs, dashboards after a few minutes of hosting the application, to ensure that the data is flowing in.

How to organize endpoints when using FeathersJS's seemingly restrictive api methods?

I'm trying to figure out if FeathersJS suits my needs. I have looked at several examples and use cases. FeathersJS uses a set of request methods : find, get, create, update, patch and delete. No other methods let alone custom methods can be implemented and used, as confirmed on this other SO post..
Let's imagine this application where users can save their app settings. Careless of following method conventions, I would create an endpoint describing the action that is performed by the user. In this case, we could have, for instance: /saveSettings. Knowing there won't be any setting-finding, -creation, -updating (only some -patching) or -deleting. I might also need a /getSettings route.
My question is: can every action be reduced down to these request methods? To me, these actions are strongly bound to a specific collection/model. Sometimes, we need to create actions that are not bound to a single collection and could potentially interact with more than one collection/model.
For this example, I'm guessing it would be translated in FeathersJS with a service named Setting which would hold two methods: get() and a patch().
If that is the correct approach, it looks to me as if this solution is more server-oriented than client-oriented in the sense that we have to know, client-side, what underlying collection is going to get changed or affected. It feels like we are losing some level of freedom by not having some kind of routing between endpoints and services (like we have in vanilla ExpressJS).
Here's another example: I have a game character that can skill-up. When the user decides to skill-up a particular skill, a request is sent to the server. This endpoint can look like POST: /skillUp What would it be in FeathersJS? by implementing SkillUpService#create?
I hope you get the issue I'm trying to highlight here. Do you have some ideas to share or recommendations on how to organize the API in this particular framework?
I'm not an expert of featherJs, but if you build your database and models with a good logic,
these methods are all you need :
for the settings example, saveSettings corresponds to setting.patch({options}) so to the route settings/:id?options (method PATCH) since the user already has some default settings (created whith the user). getSetting would correspond to setting.find(query)
To create the user AND the settings, I guess you have a method to call setting.create({defaultOptions}) when the user CREATE route is called. This would be the right way.
for the skillUp route, depends on the conception of your database, but I guess it would be something like a table that gives you the level/skills/character, so you need a service for this specific table and to call skillLevel.patch({character, level})
In addition to the correct answer that #gui3 has already given, it is probably worth pointing out that Feathers is intentionally restricting in order to help you create RESTful APIs which focus on resources (data) and a known set of methods you can execute on them.
Aside from the answer you linked, this is also explained in more detail in the FAQ and an introduction to REST API design and why Feathers does what it does can be found in this article: Design patterns for modern web APIs. These are best practises that helped scale the internet (specifically the HTTP protocol) to what it is today and can work really well for creating APIs. If you still want to use the routes you are suggesting (which a not RESTful) then Feathers is not the right tool for the job.
One strategy you may want to consider is using a request parameter in a POST body such as { "action": "type" } and use a switch statement to conditionally perform the desired action. An example of this strategy is discussed in this tutorial.

Does Apiglity provide a buil-in error handling and logging?

I'm working on an API project and have to decide over the error handling and logging strategy/concept. So as first step I want to check, whether Apigility provides its own logging functionality.
If I see it correctly, Apigility only provides a minimal error handling for REST specific errors (Apigility documentation -> Error Reporting). That's it. So, only a limited error handling and no logging. Right? But maybe it's wrong and I have just not found the functionality I need. So, is an error handling mechanism provided? Is a logging mechanism provided in Apigility?
It handles error rendering if you use ApiProblem objects to encapsulate your errors.
It doesn't handle logging out of the box, you'll have to add your application's logging strategy yourself.

Mule Web Service Consumer Warning : Operation Messages With More then 1 Part Are Not Supported

Hi I am working with Mule Web Service Consumer and i was trying to call operation with Multiple Parameters it is warning me that
Warning : Operation Messages With More then 1 Part Are Not Supported
I just want to pass multiple parameters to access my SOAP method to achieve the task.
Is this the problem with Web Service Consumer or is their any way to deal with this.
I'm afraid this is a known limitation of the web services consumer. However you can accomplish this with the cxf component.
I having the same issue and found some information around it ...
There is a improvement logged in JIRA, may help if you vote for it :)
This link suggests that you can still use WSConsumer but need to do some hand crafting of the request XML ... I could not understand what that exactly it meant so if anyone has an example on it would be great
PS: The problem I had with using CXF component is that it does not play well with the new Dataweave transformer as the Dataweave needs to be placed within the response block and from there it cannot datasense the response coming out from the CXF component
The Solution here is very simple. You just have to comment other messages and then load metadata for non-commented message (for one which you're trying to load metadata). Repeat this procedure for all the other messages and you're good to go.
Hope this helps !

Is It Posssible To Access AwesomePlayer Info And Error Messages From An Application?

I'm an untrained, newbie code hacker playing with a homebrew MediaPlayer for streaming live internet audio. An old fashioned "radio" if you will. I'm using OnInfo, OnError and OnBuffferingUpdate info to fill a "status" textView box on my player, but I see so much more detailed info in logcat from the AwesomePlayer engine. Is it possible to access the AwesomePlayer info directly from the application?
From an application perspective (assuming the application is written in JAVA), MediaPlayer is the abstraction for all player engines. There are multiple player engines such as StagefrightPlayer which internally uses AwesomePlayer and NuPlayer to name a couple.
The information made available on listeners i.e. onInfoListener, onBufferingUpdateListener, onErrorListener originates from AwesomePlayer which is translated into a generic message and is communicated through the listeners. This information is deemed to be sufficient for any application developer to develop their code around the same.
AwesomePlayer logs are more from debug perspective and helps to understand the underlying implementation of the engine. I feel that this information is good to know and understand, but not sure if this is essential for application development.
To summarize, AwesomePlayer information is actually communicated through the listeners which are generic in nature and rest of the logcat information is more for debug or understanding purposes. Currently, there is no scheme to get this information unless the developer explicitly customizes the AOSP distribution.