I am in need of a way to implement the error logging and providing a way to the admins to rtry any failure that occurs within a suitescript.
Here are my thoughts on the implementation:
Lets say for restlet i can log the datain, or the incoming data in any userevent script in a text file along with its status as success or failure. Later have a scheduled script to process that text file that may send those errors to my .Net Api and I can provide a way for Admins to retry.
Could anyone suggest me how its normally done in netsuite projects?
For similar systems, I typically advise you create Custom Records. Your custom records can have a field to store the raw data (JSON, xml, etc) as well as a Status (Succeeded, Failed, Retry, etc). You could consider retry mechanisms like having a User Event on the Custom Record that immediately retries upon creation of the record, then if that fails have a Map/Reduce that runs on a regular schedule to clean things up.
If the native Execution Logs aren't providing enough functionality for you in that respect, you can add a Custom Record for "logging" as well, but I'd suggest trying to use the native logs first. The Script Execution Logs UI provides reasonable searching/filtering capabilities.
Related
I am attempting to learn and apply the CQRS design approach (pattern and architecture) to a new project but seem to be missing a key piece.
My client application executes a query and retrieves a list of documents (with joins) from the read model. The user selects an item and clicks a button to initiate some action. The action is performed by creating and sending the corresponding command object to the write model (where the command handler carries out the action, updates the data store, etc. by read model). At some point, however, I need to update the UI to reflect changes to the state of the application resulting from the action.
How does the UI know when it is time to refresh the original list?
The operation succeeds, data has changed and the UI should be updated to reflect these changes.
The operation fails, data has not changed but the user should be notified of the failure and potential corrective actions.
Without completion of projection, I can't fetch inserted/updated data and send back to UI by a real-time sockets. One solution, I can send the state of the same aggregate and aggregateId but in case of joins, how could I send full updates back (data with joins) to UI?
You have a few options for updating the UI.
If possible, it's easier if your API synchronously returns success/failure. If you get a failure, you can immediately report to the user, and you don't need to update the UI. If you get a success, you have some options.
Include in the success response some entity version information. Include in your read model some version information, and poll the query API until the version is new enough.
Include in the success response some entity version information. Have your query API allow you to specify that you want the data as-of at least that version (in a header, query parameter, or whatever). Either you can have the query API immediately return failure if it isn't yet up to date, or you can have it block until it is up to date (with a timeout) then return the up-to-date data.
Use some kind of client notification system such as web sockets to notify the client whenever the read model it is 'subscribed' to changes. Either the notification can include the information the client needs to update, or it can make another query.
On top of those options, you can also employ the technique of optimistic updates. In this case, after making the appropriate client side checks before issuing a command, you assume instantly that the command succeeded (if it's the kind of command that usually does succeed), update the UI immediately using client-side code. Then:
If the command comes back with failure, undo the client-side update (you could do this by re-fetching the read model, or using client-side code).
If the command succeeds, consider re-fetching the read model, if there's any likelihood that the client-side optimistic update isn't quite right. This should use one of the strategies listed above to ensure the command's effect is present in the read model.
This also works quite well with offline support - you queue commands up persistently in the client, and optimistically assume they succeed (perhaps with a UI indication that you are offline and data is stale) using client-side code to update the read model, until you can actually send the commands through to the server and re-fetch the server-generated read model.
I am looking for a wait to schedule tasks based on the reception of an email.
More precisely, I received an email with some attached data every week and I need to add these data into a database (and process some information). Is there a way to do it automatically?
Would airflow be a good option to do this? I found that airflow can send email but I did not find anything about reading mails.
I know it is possible to read email and download attached file in python. But what would be the best way to check if a specific email is received (defined by a sender) and process its data as soon as it is received ?
Airflow is a great option for this workflow.
Airflow has the concept of SensorOperators which are derived from the BaseSensorOperator. Using a SensorOperator will allow you to easily control the poke_interval and timeout of the task as well as how to handle the various situations depending on whether or not the email arrives as expected.
You could schedule some BashOperator or PythonOperator that periodically checks new mail and if they find one they start processing it. While I cannot give you any specific library, I am sure there must be a way to read and handle email in Python.
Spring integration really helps us a lot during application integration, it make us more focus on flow design.
However, we want to log all file processing steps and use log analytic tools to check how one specific file(message) been processed.
Question is how to log a grouping id for each message in order to group them for checking by another logging anlytic tools?
thanks
Consider to turn on Message History for your application. This way in the end of flow you can extract such a MessageHistory.HEADER_NAME with all the traveling information for the message.
Otherwise you really don't have choice unless to add some business header in the beginning of the flow and parse logs for such a common key.
is it possible to print/log the request response while using the Netsuite API, is there any property we need to set in the nsclient.properties file that might help.
I am trying to find this so that while integrating with NetSuite, in case of any issues, I don't have to go check the API request/response logs in NetSuite.
regards,
Moin
Requests and responses are logged within NetSuite itself. You need to have the Admin role to see them.
I don't think so. I'm not pretty sure that there is any inbuilt feature in NetSuite that allows you to log the request and response of your deployed Restlet. In Netsuite there is a method called :
nlapiLogExecution(logType, title, details)
Which you can use for temporal logging/Debugging. However, it doesn't persist your logging data permanently, so you can't use the same later. Yeah, Of-course you can find many workarounds to get your task done. Create a custom record with appropriate fields for logging then inside your restlet you can write the code to create a log file for each req/resp.
I have a web application that monitors farms in certain areas. Right now I am having a problem of performing automation with some of the tasks.
Users of the web application can send reports or checkins using keywords. If the reports or checkins correspond to certain keywords, for example "alert", I need the web application to send an alert to the user via email using that web application. But that alert must be sent two weeks after the date of the report received, and to that particular user only.
Would it be possible to use cron to perform this? If not, can anyone suggest me a workaround?
A possible approach you might consider is to store an entry in a database for each of these reminder emails you need to send, at the time your user does whatever action in your application that determines the need to send that email exists. Include the recipient, the date to be sent, and the email content as content you store for each entry. Schedule a single cron job to run periodically to process these database records by due date, and populate an email template to be sent out. You can then either delete the database records, or a better option, include a column that indicates they were sent and mark them as sent.
It would help to provide which technology stack you're operating on and what the application is developed in. Others might be able to point you to technology specific approaches or pre-built plugins/extensions that already do this for the situation you're in, to help you avoid the need to write your own code for the solution.