How can I get the process instance errors and save it into any process variable?

You can write your own error handling around this. It's not great if you want to surface the details of an error but you can at least handle this gracefully.

Your process model needs to be chained. You can add one or more Boolean flags and default them all to false e.g. isDataValid, isDataWrittenToDatabase, Then as the process proceeds you can toggle these to 'true' e.g. if you have a validation step then you can update the 'isDataValid' to true. The same for the Write To Datastore. If this is successful the next thing you would do would be to update the 'isDataWrittenToDatabase' flag to true.

These pv!s will then be available to your WebAPI and you can then customise your HttpReponse according to what those flags are set to. As I said this will at least handle failures gracefully. Getting the specifics of the failure of a Write To Datastore node would be a lot more complicated (probably as an asynchronous process that trawls the logs in some fashion).

I also echo - never trust the data being sent to your WebAPI. Always conduct the necessary validations on it before attempting to write to the database (or write to a staging table with no validation, and then conduct an off-line validation exercise before committing to your operational tables).

You can write your own error handling around this. It's not great if you want to surface the details of an error but you can at least handle this gracefully.

Your process model needs to be chained. You can add one or more Boolean flags and default them all to false e.g. isDataValid, isDataWrittenToDatabase, Then as the process proceeds you can toggle these to 'true' e.g. if you have a validation step then you can update the 'isDataValid' to true. The same for the Write To Datastore. If this is successful the next thing you would do would be to update the 'isDataWrittenToDatabase' flag to true.

These pv!s will then be available to your WebAPI and you can then customise your HttpReponse according to what those flags are set to. As I said this will at least handle failures gracefully. Getting the specifics of the failure of a Write To Datastore node would be a lot more complicated (probably as an asynchronous process that trawls the logs in some fashion).

I also echo - never trust the data being sent to your WebAPI. Always conduct the necessary validations on it before attempting to write to the database (or write to a staging table with no validation, and then conduct an off-line validation exercise before committing to your operational tables).

An afterword: please consider raising a request to Appian Engineering to allow developers to conduct their own error handling so that you can do exactly what I think you're looking to do (the equivalent of a 'try'/'throw'/'catch' pattern).

What would be nice is if the Write to Data Store Entity node had a "Pause Node on Error" parameter, as does the Query DB node.  With Query DB, this allows you to continue the process (false setting) and define smooth error handling.  In older processes we have utilizing Query DB, with external databases that do go down on occasion, we have this node continuing to a Receive Message event on error - say 100 processes fail in an hour long DB outage, one click of an admin process sends messages to all waiting sub processes, back online instantly - it's a beautiful thing!