We are evaluating a chat solution for a system we are developing. Twilio Conversations is our preferred option, as we also plan to use video. Our requirement seems to be a bit atypical of most solutions, and we are trying to determine the best architecture.
The solution is for a healthcare provider. Patients will be able to chat, via a mobile app, to a number of teams in the clinic, who will converse via a web app. Clinic staff can belong to several Teams. Chats can be initiated at both sides.
We are trying to determine the best architecture for Team members. Chat responses should come from the team, not an individualand any team member should be able to continue a conversation.
So, do we have one chat user per team? This seems to make sense, except a Team member could be in several teams, so we would need to handle multiple identities.
Or do we create a group comprising each team member plus the patient? This doesn't seem the rightr approach. We would need to hide the individual user identities, keep responses in sync using horizons, and I doubt would scale well?
I'm surpised this isn't a common scenario, so was wondering if there ws a recommended architecture? Thx
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.
As part of our journey towards API-led Connectivity, we have to group our resources (i.e. API endpoints) into multiple Mule applications for the experience APIs.
In order to have meaningful names for the Mule applications while maintaining the maximum re-usability, rather than associating the consumer names with the application names (which makes the experience API tightly coupled with the current application landscape), we propose to have Mule application names to reflect the essence of the business.
The list of the options are as follows. Which one do you think is more ideal? What approach have you used in your organization?
based on Channel/Consumer
A dedicated experience API for a consumer such as WEB, CRM, Mobile etc.
uri examples:
www.example.com/example-**web**-application/v1/
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/
Pro's: - applying channel specific policies is easier, management becomes easier, smaller outage window
Con's: - reusability reduces and chances of duplication of objects across api's increases
based on Business Domain
Company data model is used. Eg - Customer, Product, Payment etc.
uri examples:
www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/
www.example.com/example-**payments**-application/v1/
Pro's: - promotes reusability, channel agnostic, same api can be used across different consumers.
Con's: management might get complex, larger outage window, multiple consumers might be impacted
based on Customer Journey
This approach is tied to the customer's lifecycle with the organization. Eg - Prospective Customer --> Lead --> Engage --> Payments --> Customer Retain
uri examples:
www.example.com/example-**prospect**-application/v1/
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/
Pro's: channel agnostic, same api can be used across different consumers.
Con's: can get increasingly big and further breakdown might still be required
Thanks.
As far I understand your question; you would like to know what URIs to be using for the endpoints of the experience APIs, right?
Based on a recent blog entry from mulesoft (July 12 2017).
Experience APIs are:
Experience APIs are the means by which data can be
reconfigured so that it is most easily consumed by its intended
audience, all from a common data source, rather than setting up
separate point-to-point integrations for each channel. An Experience
API is usually created with API-first design principles where the API
is designed for the specific user experience in mind.
Based on the examples from MuleSoft and my understanding, the experience APIs are created for one given "experience"; web, virtual reality, mobile, etc...
You are trying to create an API for a given special experience to make the consumption of the API easy for this specific client.
According to my understanding the main goal on this level is not the re-usability. You focus on re-usability on the System API and Process API level, but the Experience APIs are supposed to make the life of the developers of the different clients easier by providing exactly the interface and data they need so they don't have to communicate directly with the system and process APIs, but they get a tailor-made API, suiting exactly their special needs.
Since the experience API is tailor-made for the special experience / channel / client-application; I think respresenting this in the URI is a good idea.
I've had a Nest thermostat for a little over a year and it works well. I also have many other Home Automation devices. I'm a Software Engineer and I enjoy making my life easier by programming my own, personalized, solutions to Home Automation issues. For example, I have my own weather station which reports information to Weather Underground using my own custom software. I also have my own, home grown, web interface which integrates both the X10 devices in my house and also the Wink devices, on one page.
I would like to gather temperature readings from my Nest thermostat and integrate that information into my home temperature information, in order to get a better idea of what is happening in my house. I signed up to be a Nest Developer and jumped through all of the hoops to get an access token in order to use the REST API. They turned me down!
So, it sounds as if Nest is not allowing their customers to access the information from your own thermostat in your own house! I find this closed system unacceptable! If Nest will not allow me access, then I guess my only alternative is to replace my thermostat with some other model which is more open and accessible?
Have others run into this closed system? Is there a way to deal with it, or is Nest simply saying, "we want your personal temperature information history, but we're not allowing you to have it, yourself."
Apparently, you don't need to get approval. Just proceed with describing the program, etc., and get the pincode. It works fine for a small number of users (50, I think) without approvals.
I use Skyscanner a lot myself, and one thing I don't like is the fact that I get redirected when I want to book. I want to know what the obstacles are in having a solution where you can book your flights without being redirected and without necessarily being a reseller/travel agent.
The objective is to make comparison shopping seamless.
I understand low-budget carriers prefer booking only on their site, but perhaps their strategy can be integrated within the comparison site.
I also understand that carriers would want customer analytics, but this can be made fully available to them.
What are the reasons for example KLM, Airfrance etc might NOT want to make comparison shopping seamless?
I have been a main developer for one of such website which uses such APIs. I would list many reasons but also it is a good practice not to do so.
Just some reasons off the top of my head.
1) It is not the purpose of such websites. They just join an affiliate program to redirect users and get some small fees for purchases. They would keep their system as simple as possible.
2) Airline and other provider like hotels have their own policy on fees, refund, purchase, loyalty points etc. As a third party, you can not implement such a thing for each provider. If you dont implement, then you would use API, right? They wouldn't expose such inner workings of their system to third parties, payment involves PCI compliance, customer confidentiality etc.
3) Such services involve certain confidentiality and privacy. Somebody's passport, staying at a particular hotel or flying on a particular plane is sensitive information and should not be available to third parties.
Just imagine how many third parties their API are available. No trusted company would allow this to happen.
4) Even if they allow, no third party can really ensure security of such sensitive information. If a breach of security happens, thousands of airline data etc. would be affected.
5) Each of airline and hotels might be subject to different jurisdictions in terms of data protection etc. It is technically impossible to combine them.
many many other reasons..... There are also many issues in handling payment, accounting etc.
I have been asked to create a site on which users can invite each other to play a game on a specific gaming console (X-Box or PS3 for example). If the players do meet online and play, the site needs to monitor which of them won - then distribute prize money to the winner.
Can anyone point me toward a reference for monitoring the gaming results through some kind of API on these various platforms?
I can't speak for PSN or the PlayStation 3 (although I assume it works very similarly), but for the Xbox 360 and Xbox LIVE:
There is no single API that will enable you to access wins/losses for every multiplayer title - each title would need its own individual API.
Very few developers provide public APIs for their games with statistics for wins/losses.
Microsoft does provide registered developers (and some community members) with access to some Xbox LIVE APIs (which provide achievement, game, and profile related data).
So, what you want to build is not possible using APIs unless:
You are only tracking stats for one specfic game which does have a public (or otherwise accessible to you) API; OR
You are a registered developer and have access to some NDA APIs which provide the information you seek (for example, leaderboard information for XBLA titles, achievement/trophy data, etc.).
You may need to find some other method for verifying the winner.