we're currently working on the design for an UCMA application that should be able to subscribe to presence updates of up 15k users. Reading the (rather outdated) documentation we noted the following:
Lync Server 2013 also places a limit on the subscription response body length, so an application that subscribes to a large number of users (typically more than 1000 users) might receive an error response from Lync Server 2013.
Does anyone know if this still true for Skype for Business 2015/2019 or where to find current docs?
Further down the same doc states that, for a large number of subscriptions, it is recommended to limit the categories we subscribe to. We're only interested in the presence state, so that's a good workaround for us. However I can't find much information about what difference that makes, like if we subscribe to only the presence state, can we have 2x or 5x or 100x the number of subscriptions?
Searching around I found this post that seems to say we can subscribe to many more users if we create batches of a few hundreds. So does the above limit of 1000 users apply per BeginSubscription() call?
Many thanks in advance!
Sounds like you are reading the UCMA 4 (Lync 2013) documentation.
There is the UCMA 5 (SfB 2015) documentation but there are no real differences.
UCMA 6 (SfB 2019) is available but there isn't any documentation.
From personal experience, you can use any of the UCMA versions to get the job done. The details haven't changed.
If you want to subscribe to SfB online accounts, you will have to use UCMA 5 on SfB 2015 or UCMA 6 on SfB 2019 as UCMA 4 on SfB 2015 / 2019 doesn't work for SfB online accounts. The is the only gotcha I have found.
I've gone up into a 100's of subscriptions and I think some of our customers are up to around the 1k mark using batch subscriptions. I use a batch size of 100 and it's working ok for me.
You are not going to know until you test it yourself to see how to performs with batch sizes you test with if it's to slow or fast enough.
At the 15k mark, it's getting to be a lot of subscriptions to take care of. This may start putting unwanted overhead onto the SfB system at that level of subscriptions due to the extra messages / subscription polling going on. You may need to look into splitting the subscriptions between applications / machines to load balance the work.
If you find that it's not working very well you may need to think about switching from a UCMA application to a Server App (sip proxy) application that runs on the FE machines and sniffs the sip traffic to view the presence change traffic as they happen. It's a lot more work but would not generate as much overhead as a UCMA application.
Related
What considerations are needed when creating a web app that is intended to be used in an industrial plant setting for a company? My specific use case is an industrial facility with several different production plants that would each have its own device for the application interface.
How do companies enforce the usage of such apps on a monitor/tablet? For example, could I prevent them from using other stuff on the tablet?
Importantly, how would security work? They'd share a device. There may be multiple operators that use the app in a given shift. Would they all use the same authentication session (this is not preferable, as I'd like to uniquely identify the active user)? Obviously I could use standard username/passwords with token based sessions that expire, however, this leaves a lot of potential for account hijacking. Ideally, they'd be able to log on very quickly (PIN, perhaps?) and their session would end when they are done.
As long as there is internet connection, I would presume that there isn't much pro/con regarding the use of native applications versus web based or progressive web apps. Is this assumption correct?
What's the best way of identifying which device the application is being run on?
Is this a common thing to do in general? What other technologies are used to create software that obtains input from industrial operators?
--
Update - this is a good higher level consideration of the question at hand, however, it has become apparent why focused, specific questions are helpful. As such, I will follow up with questions that are specific.
Identifying the Area/Device a Web Application is Accessed On
Enforcing Specific Application Use on Tablets
Best Practices for Web App Authentication in Industrial Settings
I'm not able to answer everything in great detail but here are a few pointers. In the environment as you describe we usually see these two options. 1) you tell them what you need, internet, security, if they give you device and how it will be configured 2) they tell you exactly what you need to deliver.
I do not think you can 100% prevent them. We did it by providing the tablet( well laptops in our case) and the OS configuration took care of that, downside we had few devices to support. You seem to hint that there is always an internet connection so I guess you can collect all info about the system and send it back to you daily?
We were allowed to "tap" into their attendance SW and when you entered the facility you were able to use your 4 digit pin to log in if you were out of premisses you could not log in at all. I can imagine the following: you log in with your username and password - this does full verification, after that, you can use 4 digit pin to login for next n hours.
maybe, kinda, depends on what you are doing. Does the browser have all features you need? Our system needs multicast to perform really fast, so we have a native app
touched on this in 1. You could also use device enrolment process. You can also contractually force them that there will be only your software and it may invalidate support contract. It really depends on your creativity. My favourite( and it works - just tell them, there will only be installed my software and if not you will pay me double for support. I only saw one customer who installed some crap on the device when there were told not to
it really depends on what industry you are talking about, every industry is different. We almost always build a custom solution
The enforcement of the device/app usage depends on the customer, if the customer asked for help in the enforcement, then you can provide guide, training and workshops. If the customer serious about the enforcement then it will be a policy that's adapted by all the organization from top to down. Usually seniors will resist a workflow change more than juniors, so top management/executive should deal with that. Real life story: SAP team took 6 months to transform major newspaper workflow, during that few seniors got fired because they refuse to adapt the change.
Security shouldn't handicap the users, usually in industrial environment the network is isolated or at least restricted through VPN to connect multiple sites (plants in your case), regarding the active user: we usually provide guide/training/workshop for the users and inform them that using colleague account or device will prevent the system from tracking your accomplishment/tasks, so each user is responsible to make sure the active account/device is the one assigned to him/her.
It depends, with native you have more controls than web, but if the app is just doing monitoring then most of today apps use web for monitoring and the common way to receive input is REST APIs (even if the industrial devices doesn't support REST API, a middleware could be written to transform the output). If you need more depth about native vs web you need to ask new question with more details about the requirements.
Depends on the tech you are using (native or web), and things I mentioned in point 2: you can use whitelist of devices that's allowed to run the app. overall there are many best ways to track down the device.
How common in general? I think such information can only be achieved by survey, the world full of variations. And having something common not mean its safe or best, our industry keep changing at all levels. So to stay in the loop, we must keep learning and self-updating without reboot.
I have a project where I need to have the API quota increased significantly from the 10,000 daily hits, and I think this is being processed by Google as part of a YouTube API Services Compliance Review.
However, I have not had any response in over a week and the delay is putting the project at risk of a delayed launch and additional costs.
Does anyone know if this is normal and if there is a way to expedite the review, or speak to someone? Even pay for a higher tier of support?
Thanks in advance.
If you’ve filled the audit form https://support.google.com/youtube/contact/yt_api_form?hl=en properly, you should get a response within two weeks (Google reviews thousands of these, among other things to prevent abuse this is one of the processes that isn’t fully automated).
I recommend if your in a rush since your paying for credits you might as well open a second account and load balance between two or even three accounts; in your code you can create counters and swap before capping out the 24 hour term; not sure what data you’re looking to extract but depends on what data you may be able to even use other services to supplement.
They will get back to you about your application; just requires massive patience.
I was not able to find any information about the maximum number of concurrent requests and maximum number of requests in one second to the Visual Recognition service.
Can you provide me with information or link where I can read about limits in general?
There is not a hard limit on concurrency per user. The service is designed to support many users simultaneously, and therefore has capacity to process many requests in parallel. During periods of heavy use however you may occasionally receive a 500 return code, in which case the request should be resubmitted.
Unfortunately there is a legacy error message in the system that tells users they may be submitting too many concurrent requests , but it is very unlikely that the error is actually caused by a users' concurrency. They should be treated like a 500 error code - just resubmit the request.
You should have no problem submitting 30 or 40 requests concurrently.
Standard API keys are limited to 25,000 events per day by default to prevent something like an infinite loop from generating a huge bill. You can have that limit increased by creating a bluemix support ticket. If you really want to do some large scale processing in parallel it would also make sense to get in touch with Support with a bluemix ticket so that we can guide you in the most cost effective and efficient way to use the service.
My goal is to maintain "real-time" (or as close as possible) information about the email messages sent by a group of users.
My ideal solution would be to periodically query the API for messages by all users in the group. This feature is not (yet?) implemented.
My second choice would be to create subscriptions (https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/subscription_post_subscriptions) for every member in the group and then request message information after I become aware of an event. The problem is, in practice, I am only allowed to create 20-30 simultaneous subscriptions (Issues to use Webhook for Microsoft Graph API), which might not be enough.
So I'm stuck with polling all the users in a cycle. The main problem with this approach is I can't find any information how many request are "too many", ie I get throttled. I want to maximize the number of requests to minimize the time it takes to get through one cycle.
A solution that comes to mind is to develop an adaptive program that slowly decreases the time between requests until throttled, then abruptly adds some time to it until a nice balance is found and maintained. This seems like a lot of work though. Right now I'm working on the assumption that 1/second is about the highest I can safely go (0.5 seconds on average per round trip, then a cool down of another 0.5 seconds).
What is the best way to deal with an unknown throttling limit in general, and Microsoft Graph in particular?
Edit:
While I think the accepted answer is a good response, it might not be suitable for all cases. For instance, if you don't want to use the 365 API, and you don't mind using beta features, perhaps you might check out this (delta tokens), which seem to be designed for real-time syncing with the data.
The only potential downside with the accepted answer is that you still need a subscription for each user you want to track (I think...), and there are limits on those. Very curious as to how other people tackled this problem.
While still in Preview, you may want to take a look at Outlook Streaming Notifications. These APIs provide a more robust notification model than simple web hooks. You would still need to establish multiple subscriptions but I expect you'll see far less latency.
I have a requirement where I need to develop a web application in which two application users negotiate with each and later after agreeing on terms they are to trade illiquid bonds via Bloomberg. For this I need to generate the BXT and SXT Trade Tickets through my application. The question really is that is this even possible without the Terminal?
A white paper on Bloomberg API's website says
Other applications are possible, for example submissions of trade orders
But I am not able to find any reference or example how this can be achieved using Bloomberg API or any other service provided by Bloomberg.
I'd be surprised if you are able to do this, by definition a web application is hosted on server x and interacted with from device y. Bloomberg's entire business model is based around having a Bloomberg terminal on device y.
I'd recommend you look at other bond trading platforms not just Bloomberg, e.g. TradeWeb, MarketAxess or even the large brokers e.g. ICAP, Tullett who may have a more suitable API.
This might come a little bit late but you might want to have a look into Bloomberg's FIX API. I am working on a similar project and I have implemented this functionality in a web application that creates and sends Trade Tickets via FIX. You do not have to have a Bloomberg terminal installed. Your FIX session will connect directly to a Bloomberg FIX endpoint.
Bloomberg has a test environment for this. You have to contact one of their representatives and ask for a Beta FIX Session.
FIX is a publicly available protocol for exchanging financial information. A good starting point would be https://en.wikipedia.org/wiki/Financial_Information_eXchange