Here i am troubled out with a issue with my drop point.
Here is the scenario:
-> we are using JAVA POST api for inserting values in sage database(Using flowgear sage evolution node).
-> when we are online, and the workflow is called from api then everything works fine.
-> But when i am offline or out of internet(my workflow is not call)
then it gives workflow offline error.
i.e "DropPoint '****-***' is offline and is required for this Workflow".
So, is there any way to manage the hits and dataloss when we are offline. [i will miss my data to be inserted in sage when i am offine and api will be called]
Please can you guide me on the same.
Thanks
Flowgear isn't really intended to handle this. It would be best to cache content to be sent at the source and have the ability to keep unsent data until it is successfully integrated.
That said, here would be the recommended way:
Decide where to store unprocessed data. If it's a small amount of data you could use the Flowgear Cacher or Statistics but it's probably best to have a database (eg. SQL in Azure)
The workflow that is bound to a REST endpoint and is called from your app should be modified to ONLY store data in the intermediate store described above. (i.e. its role is to queue data).
Create a second workflow that uses a timer or trigger to check for data in the intermediate store and process it.
Related
Good evening everyone .
I am developing a react native app by interfacing to a database via endpoint (specifically aws).
Now on loading the dashboard I retrieve this data via API , save it in local storage and show it to the user.
Now from the management system, there could be some changes to this data that I show on the app, so what I was interested in knowing was if it was possible to create a sort of listener that calls my API whenever there are changes in the DB. I ask this because I would like to avoid calling the API every time a user lands on the dashboard and I would like to avoid calling the API every XXX minutes if there is no reason (if the data has not changed).
Is there any way to create an event listener? It would also be enough for me to be directed on what exactly to look for.
Thanks in advance for your availability
I want to show different kind of notes in my vue.js application to inform the user for example about an upcoming maintenance. I thought at an info "banner" under the application header. The data like period of the maintenance I would store in a sql database. In this database I want to regular when the banner should be visible or even not. Maybe with a table column called active.
Now I am looking for a solution how to trigger the vue.js application to refresh if data in database was added/updated.
Can someone help me please?
Are there any other ideas (maybe more professional ideas) how to trigger a note "banner" in a vue.js application?
The application will be hosted in Azure.
Thanks in advance!
Anatoly answer is right, those are your two options. You either make a request to your backend service every couple of minutes(depends how fast this info is changing) or you implement a web socket that will let your frontend now when the info has changed. It depends on how big is the app and what use you're going to give it, personally, in a scenario like this i would go with a web socket.
Here you have a nice library i've used in the past: https://www.npmjs.com/package/vue-socket.io . You will also need to make some implementation in your backend service to handle the info gathering.
I have a web application that displays inventory, orders, tracking information from drop-shippers for orders and tracking updates. When a customer logs in, he will see all the above information in different pages.
I have a Console based application in the server that hosts 4 background workers to do each of the above tasks and updates the database. Now i have one console application for each customer. I did this because for any reason the console application fails because of one customer's data, it should not effect others.
Is there a better approach or any existing tools, api, frameworks available to support this kind of stack in Microsoft? Or what i am doing is correct and best approach? Are there any technologies that are more stable to support Subscription based membership, Offline data sync, Queue User requests and notifying user when they are completed.
I would take a look at the Azure Queues and Webjobs (Links below)
With a queue structure, you can simply decouple your application and make the application only do what is needed. Your main application can then just put relevant and needed information in the Queue and forget about it.
Next (and perhaps the most crucial part of this) you can write a simple console application that will run when a queue is present and ready. The beauty of this is that you not only can have multiple webjobs doing the same thing (I don't recommend it) but also, you only need to have and maintain one Console application. If the application crashes, it will simply restart it again (within a few seconds) and go back at it again.
Below, please find a link to the tutorial of how to make a sample Queue and Webjob:
http://azure.microsoft.com/en-us/documentation/articles/websites-dotnet-webjobs-sdk-get-started/?rnd=1
Using Wufoo's API, is it possible (and if so how) to retrieve a single entry and update the information in it (without submitting it as another entry)? I can't seem to find any information on the Wufoo API website. If this isn't possible, any suggestions as to to work around this (such as using a local db). I'd like to build a hybrid app that authenticates locally and uses Wufoo for the data collection.
Thanks :)
I've been working on a similar kind of project and ran into the same issue. After submitting a help ticket, I was informed that the wufoo API does NOT support this function (update). Any updates would have to be done externally.
Like you, I would like to store my data in wufoo rather than externally, so I'm working on a few scripts that will serve as webhook endpoints for my wufoo forms. Whenever a form is submitted, one of these scripts will receive that data, do stuff with it, then use the API to relay the modified data back to a second wufoo form that "shadows" the original (same fields if needed, or new fields that reflect the processing I did).
This second set of forms would be the final destination for the data and only be accessed by my code. The first set of forms would only be accessed by live users. In a nutshell, it's a huge feedback loop that uses webhooks to trigger the processing.
Hope this helps.
for more info on webhooks, see http://help.wufoo.com/articles/en_US/SurveyMonkeyArticleType/Webhooks?q=webhook&fs=Search&pn=1
for more info on the wufoo api Entries api (get & post), see http://help.wufoo.com/articles/en_US/SurveyMonkeyArticleType/The-Entries-API
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.