I'm using the Installation approach to handle my push notifications.
Works great!
However, how can i update tags for an installation via the backend, without knowing the installationId?
E.g with Registrations, i can do this:
_hub.GetRegistrationsByTagAsync("member:1")
To then update all registrations for that user, via my backend.
But how do i do this with installations? There is no equivalent GetInstallationsByTagAsync, there is only GetInstallationAsync, which needs the installationId (which i don't have, since this a backend/background operation).
Notification Hubs does not have a getInstallationByTag method available at this point in time so Installation IDs would be necessary. It is on our roadmap to provide a complete set of registration equivalent support for installations.
Related
I'm trying to figure out how to use the recommended approach from Microsoft and use the Installation Model to handle registrations.
I want to be able to get some information about the installations that should have been saved and I see that there are two methods that could be useful
GetInstallation(string installationId) and GetInstallationAsync(string installationId)
Problem is that when making at call to any of them I never get a response back. I can't figure out what I might be doing wrong.
Here's the answer from a similar question (that still holds true as of Nov 2016):
... there's no way to get all installations for a hub. In the future, the
product team is planning to add this feature to the installations
model, but it will work in a different way. Instead of making it a
runtime operation, you'll provide your storage [account] connection string and
you'll get a blob with everything associated with the hub.
The company I work for uses SharePoint Online. We have a requirement that on most site collections, whenever a user creates a new document library that the document library is configured with the "document" content type being removed, and replaced with some of our own corporate content types.
Previously I've managed this by using a coded sandbox solution installed on relevant site collections which had an event handler that fired on "list added". It's obviously now time to move away from that solution.
I'm really struggling to get to grips with the alternative, conceptually. I'm aiming to replace the old solution with a Remote Event Receiver solution.
The way I think I'd like to achieve this:
1) Create a single remote event receiver hosted in Azure which receives details of a new list being added in a site which it then configures appropriately.
2) Use CSOM to provision the site and as part of that provisioning, hook up the event receiver.
I've spent a lot of time on this, getting nowhere. I initially thought the answer lied in using an App which I could install in the App Catalog and then push out to particular site collections but that doesn't seem to be right.
Is the solution above possible? All examples on the web I've come across of setting up remote event receivers seem to use a SharePoint app which I don't really want to do.
Thanks.
For info I found the answer. You can indeed create a remote event receiver without a SharePoint app/add-in.
The answer was written up here
I thought I needed a SharePoint Provider Hosted App for that part 1
But you should bear in mind that as per Remove event receivers on host web clientContext you will not have the client Context passed through, so
TokenHelper.CreateRemoteEventReceiverClientContext(properties)
...will come through as empty. If you want to interact with SharePoint then you'll need to find another way than this approach, or use a different set of credentials.
When I append a new subscription in ORION, it automatically evaluates the condition and it invoques the designed end-point for that. I want that the new subscription affects only entities appended later.
Is there any way to avoid it or I have to control this at end-point level?
Related to this, is there any batch option to create several subscriptions at same time for a initial load of the platform?
Orion Version: 1.2.0
Regarding initial notification:
No, it isn't.
We understand that for some uses cases this is not convenient. However, behaving in the opossite way ruins another uses cases which need to know the "inicial state" before starting getting notifications corresponding to actual changes. The best solution to make everybody happy is to make this configurable, so each client can chose what it prefers. This feature is currently in our roadmap (see this issue in github.com).
While this gets implemented in Orion, in your case maybe a possible workaround is just ignore the first received nofitication belonging to a subscription (you can identify the subscription to which one notification belongs by the subscriptionId field in the notification payload). All the following notifications beloning to that subscription will correspond to actual changes.
Regarding batch option to create several subscriptions
No, there isn't any operation like that.
EDIT: the posibility of avoiding initial notification has been finally implemented at Orion. Details are at this section of the documentation. It is now in the master branch (so if you use fiware/orion:latest docker you will get it) and will be include in next Orion version (2.2.0).
For example, I have a website with various types of information. If that goes down I have a copy of the same website the users use on a local webserver, like Apache or IIS on the client. They use this local version until the Internet version returns. They can have no downtime, in other words.
The problem is that over time the Internet version will change while the client versions will remain the same unless I touch each client's machine to make the updates. I don't want to do that.
Is there a good way to keep my client up to date so that when I make a change on the server the client gets a copy so they can run it locally if needs be?
Thank you.
EDIT: do you think maybe using SVN and timely running of the update by the clients would work?
EDIT: they'll never ever submit anything. It's just so I don't have to update the client by hand, manually going to the machine. they're webpages that run in case the main server is down.
I will go for Git over SVN because of its distributed nature. Gives you multiple copies of code; use it along with this comment's solution:
Making git auto-commit
to autocommit.
Why not use something like HTTrack to make local copies of your actual internet site on each machine, rather then trying to do a separate deployment. That way you'll automatically stay in sync.
This has the advantage that if, at some point, part of your website is updated dynamically from a database, the user will still be able to have a static copy of the resulting site that is up-to-date.
There are tools like rsync which you can use periodically to sync the changes.
I want to write a workflow application that routes a link to a document. The routing is based upon machines not users because I don't know who will ever be at a given post. For example, I have a form. It is initially filled out in location A. I now want it to go to location B and have them fill out the rest. Finally, it goes to location C where a supervisor will approve it.
None of these locations has a known user. That is I don't know who it will be. I only know that whomever it is is authorized (they are assigned to the workstation and are approved to be there.)
Will Microsoft Windows Workflow do this or do I need to build my own workflow based on SQL Server, IP Addresses, and so forth?
Also, How would the user at a workstation be notified a document had been sent to their machine?
Thanks for any help.
I think if I was approaching this problem workflow would work to do it. It is a state machine you want that has three states:
A Start
B Completing
C Approving
However workflow needs to work in one central place (trust me on this, you only want to have one workflow run time running at once, otherwise the same bit of work can be done multiple times see our questions on MSDN forum). So a central server running the workflow is the answer.
How you present this to the users can be done in multiple ways. Dave suggested using an ASP.NET site to identify the machines that are doing the work, which is probably how I would do it. However you could also write a windows forms client that would do the same thing. This would require using something like SOAP / WCF to facilitate communication between client form applications and the central workflow service. This would have the advantage that you could use a system try icon to alert the user.
You might also want to look at human workflow engines, as they are designed to do things such as this (and more), I'm most familiar with PNMsoft's Sequence
You can design a generic "routing" workflow that will cause data to go to a workstation. The easiest way to do this would be to embed the workflow in an ASP.NET application. Each workstation should visit the application with a workstation ID in the querystring:
http://myapp/default.aspx?wid=01
When the form is filled out at workstation A, the workflow running in the web app can enter it into the "work bin" of the next workstation. Anyone sitting at the computer for which the form is destined will see it appear in their list of forms to review. You can use AJAX to make it slick and auto-updating.