I am currently working on a project where we are planning on using WF4 services. We also need to save the workflow progression by using bookmarks.
Are the bookmarks in WF4 stored on client or server side?
and is it a way to decide where it is saved ?
After a few refined Google searches I found the answer to my question on MSDN.
Bookmarks are stored in the persistant store on the host/server side.
In order to store the bookmark on the client side I need to extend the abstract class InstanceStore. then stream/save the file(xml) to the client.
I will make sure to have at least 1 cup of coffe the next time I ask a question.
ref:
https://msdn.microsoft.com/en-us/library/ee829481(v=vs.110).aspx
Related
I'm building an app which uses user contributed content.
The contribution by each user should be available to all others in real time.
I was looking into firebase Realtime database for this.
However, when a user contributes content, there are quite heavy validations and calculations (read server side) to be done on the data before making it available to others.
Is it possible to have a server side validation in firebase ? Or should I look for alternatives ?
Initially, Firebase did not have a feature to implement server-side processing/calculations. All your processing had to be done on the client side.
Now, they've recently introduced a new feature called Cloud Functions For Firebase. Its a really useful new addition where you can write server-side code without the hassles of managing servers or instances. Read up more about it from the above link.
Also, this Youtube playlist by Jen Person is a great start. And, you can find examples similar to your use case here.
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
I'm developing a software system which receives information (which is saved to a database) and when any information is received (new insert in a specific table) an alert should be seen in the screen in the information center, so proper action can be taken.
I'm writing an application with ASPNET MVC, SQL Server 2008 Express, SQL Agent free for that version of SQL Server, Entity Framework 4, Visual Studio 2010, etc.
Right now, I've set the database and a SQL job that monitors the table each minute, if there is a new records an email is sent to same addresses. My problem is...What then? Which would be the best architecture to follow?
A couple of option I thought about are:
1) In the job connect to a web service and that web service an the web service can open a popup
2) The web page could be pooling the database table to know if there are new records
Is there any way to make push to the web page instead of the page pooling the database server?
I know maybe windows application would fit better here, but right now I must stick with ASPNET MVC as I already started and don't want to create another application.
Thanks! Daniel
Is there any way to make push to the web page instead of the page pooling the database server?
HTML5 WebSockets. Draft, pretty new, specification is still subject to change, to all browsers implement it. You will need a WebSocket Server. If you go that route make sure you read this guy's blog. He is behind Laharsub which is a must try server.
I'm pretty sure you are able to use Silverlight to push data down to the client. Here is a pretty good overview that I read a while back. HTML5 might be a better way to go. But with such limited support it's almost not worth it at this point. Granted the Silverlight application might be out of reach to, but it's still a possibility.
I would suggest that you look into (complex) event processing, or stream processing -- at least to get the feeling for architecture of these systems.
The idea is to capture a stream of events before they reach database, route them (process) within the event processor and put them in the DB from there -- treating the DB as only one of event destinations (subscribers).
Take a look at Streambase, ruleCore, and many others.
These were all developed for the type of scenario you described.
Try to see the problem from the other angle. Develop a web client that reads the database every minute and compare to last pull ...
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.
I want to enable an user to be able to communicate with other users through a site. I know that ASP.net is stateless, but what can I use for this synced communication? Java servlets?
I don't think you need to set up Java just to use a servlet for this. I would use AJAX and the database. I don't know ASP.NET but I PHP is similar in this case, being also basically "stateless". If you want to display some kind of asynchronous communication between two different users, say, from two different sessions, without a lot of refreshing (like chat), you can have the AJAX page constantly poll the database for new messages, and display them when they come in. You can also use AJAX to insert the new messages, giving the user read/write access to this messages data structure. Since the "other" user is doing the same thing, user A should see new messages pop up when user B types them in.
Is that what you mean?
You probably don't want to use sessions for things like chat messages but you probably could use some type of implementation of queueing using MSMQ.
The approach to chat could be done in many different ways, this is just a suggesting off the top of my head.
Could do a messaging solution in Java Servlets using the application context. Objects stored as attributes in the application context are visible from anywhere in your webapp.
Update: Chat like functionality... I guess that would be AJAX polling your message structure stored in the app context unless you want to use something like applets.
Don't know if it's any good, but there's a chat servlet here that might be useful to use or learn from if you decide to go the Java route...
ASP.NET is "stateless" but it maintains state using Sessions. You can use them by default just using the Session[] keyword.
Look at ASP.NET Session State for some details from Microsoft.