I have a workerrole which creates a PDF document. I pass the workerRole the needed data trough a queue, the worker role creates a PDF document, stores it in a BLOB, but how can I send the BLOB address back to the website to inform the user where to go to download the PDF?
That's a typical scenario for the Correlation Identifier pattern.
When the worker role is done, it should send back a message over a queue indicating that the document is ready. You can use a Correlation Identifier (such as a document id) to indicate on the DocumentReadyEvent message which original request this event relates to.
You could also go the route of full CQRS and simply update a view-specific table that includes the new document, and let the web site query from that.
You could do it the other way around using a common naming framework. Let the website/user application choose the name and location of the blob based on some standard convention. The site/app can then occasionally check for the blob via an http request.
But, do you want to inform the web user in real time about the ready document?
You can do lot of things, for example you can create a table partitioned by "user id" and store the url of the finished documents there, and set up an ajax call that checks in background the content of that table for that user regularly, and when it founds a new one that has not been "viewed" yet, show a warning with a download link.
Just an idea.
Related
Is is possible to get latest dalta link for messages and do not iterate through all messages until we reach last page?
/v1.0/me/mailFolders/{folderId}/messages/delta API
From documentation https://learn.microsoft.com/en-us/graph/delta-query-overview "Resources stored in Azure Active Directory (such as users and groups) support "sync from now" scenarios. This allows you to skip steps 1 and 2 (if you're not interested in retrieving the full state of the resource) and ask for the latest deltaLink instead. Append $deltaToken=latest to the delta function and the response will contain a deltaLink and no resource data."
But that does not work for messages how i understood. Is there another way to do this?
I am trying "update handlers" to catch create/update/delete events in IBM cloudant. It works when a document is created or updated, but not deleted. Is there any other way I can catch an event that a document is deleted and then create a document in another database to record this event? Thank you.
If you want to monitor a couchDB/Cloudant database for changes take a look at the /_changes feed: http://docs.couchdb.org/en/2.0.0/api/database/changes.html. You could implement an app that continuously monitors the feed and "logs" the desired information whenever a document is inserted, updated or deleted. For some programming languages there are libraries (such as https://www.npmjs.com/package/follow for Node.js) that make it easy to manage/process the feed.
I have just set up and created by first ever SharePoint development effort: a project for a web part, to be hosted in a SharePoint Online instance (my Office 365 trial).
I have figured out how to use the List API to pull the content I am supposed to present, being a rotating list of banner images, but I have one remaining concern. I would like to keep track of where in the list I am, and when last I changed images. Another question of mine answers this quite nicely if I go with local storage, but is there any SharePoint REST or JSOM API I can use to persist this state in the SharePoint service?
I like the local storage answer, but you could also write the state information to another SharePoint list.
Keep track of the information on a per user basis (probably against their user ID, since they'll likely be authenticated) and have send an AJAX request or a JSOM request without any visible callback behavior each time the viewer's state changes (maybe even use a web worker for users that support them).
Writing info to SharePoint lists isn't the fastest operation in the world, so it's possible you could have the banner rotate, the request fire, and the user close the browser before the request was complete -- but in that case they would just wind up on the same slide they were at before (so just repeating the last step in the rare occassion where this happens).
I have this sample application regarding Change Requests.
If the form is saved, it will send a form as an email to the listed approvers.
The form has 2 actions - Approve and Reject.
Let's say the approver approves the CR. It will update the emailed form document but the document that resides in my local database won't. Is there a way for me to update the documents in my local database automatically if the recipient(approver) has approved/rejected the document form?
Not automatically, but you can add logic to the approve and reject actions to update the database.
If this database is shared on a server, one way would be to make it a mail-in database. Your approval actions could then trigger an email that goes to that mail-in database address. Your database would then need an agent to process the emails, perhaps simply just parsing the subject line which could contain the UNID or some key that says which document to update along with the response of approved or rejected. This would work in a distributed environment.
If the environment is not distributed, say everyone is always on the same network connected to the same Notes server, then you could write some Lotusscript code to update the remote database directly.
Remember the context that you'll be in. When the emailed form is open in an approvers Notes client, he or she doesn't have access to your local databases. So you'll need to have a place on the server that the response action can update.
The safest design for a highly distributed workflow application, (replicas on multiple servers and local replicas on users laptops) is to have the approvals and updates posted as new responses and not have updates directly to the main WF document. The WF document should then compute the statues based on the responses. Finally, an agent running on ONE server can post the status updates to the document and archive the responses.
This construct will eliminate (or reduce significantly) the possibility of replication and save conflicts. It is particularly needed for WF items that require multiple approvals from people who are disconnected or connected to different servers.
This is a common problem that I find when programming a Lotus Notes App.
Use case: An employer fills out a request form in a Request database. A notification gets mailed to the person that may give them OK or REJECT for that request. The authority person visits the Request database and gives OK or REJECT.
Good. But, where would you save the approval status OK or REJECT:
Should the authority person have write access to the original request
and set the status directly (and may alter other data in the form)
Should the aproval action create a response doc to the original (and i cannot show in a view the current status)
Typically you are better off setting an approval status directly on the request. That may not seem initially ideal, but remember Lotus Notes isn't like a relational database where things would be more normalized.
Let's consider the alternative, putting a status in the response document. Now how do you show all the requests with their statuses? You'd probably have to write some code just to do that when with the first option you could just create a view.
You can control the access to the document using reader and writer access fields. See how the built in template does it (the approval workflow template). Essentially as the document changes state (i.e. New, Submitted for Approval, Approved or Denied, etc), you can also change the reader and writer access fields at that point.
Once, I designed a database that mailed that request to the approver with the form stored in the document. As long as the user accessed the document using a Notes client, they could click on a button in the message to approve, which would send a message back to the database with the field data to mark the request as approved. An agent in that request database was set to run when new mail arrived, read those messages and change status on the original requests. That way, the approver never had to leave their inbox and didn't even need rights to edit the request.
You could do it with URLs if the users would be approving via browser client - have the link to an agent and pass in the parameters.
Or, to go back to your scenario, once the requester has submitted the request, don't display the fields that you don't want changed, display the values as computed text instead.
Anyway you look at it, best to have the approval recorded on the original document.
For above, Everything is our concern. In SQL or any other RDMS, we are in need of normalize that. Similarly here we have view categorization, show response document in hierarchy, and a lot of great hide when functionality based on role, ACL, unique person and whatever you need. We can easily manipulate the data render depends on the current user.
For your Q:-
1. We can control the appropriate user[authority person] from editing the request form's item.
2. We can also do by the response document. There we can show the documents in view by using show the Response documents in hierarchy.