We are reading the LwM2M 2m spec for a college assignment simulation and trying to implement client and server requests.
Finding it hard to understand few details. Documentation is limited on it. We were told a requirement was to configure multiple clients. Does that mean each end point will have its own object ids according to LwM2M? What will be unique for each client? What we understood was each client has several objects like location, device, access control, security etc. Is there any good documentation out there or can someone give us a pointer for basic hierarchy of LwM2M?
LwM2M server registers client devices by uniqued endpoint name. To understand the lwm2m server and client flow better, you should play this demo sand box from leshan lwm2m
https://leshan.eclipseprojects.io/#/clients
You can read this to understand more about API in lwM2M
https://www.win.tue.nl/~lrahman/iot_2016/tutorial/LeshanTutorial_2016_v2.pdf
Related
https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/
Our organization is finding this announcement somewhat problematic! We use an IMAP library extensively to read various service based email accounts in o365. Any guidance on how to address this would be greatly appreciated.
Note, we have many console apps written in .NET (4.8) that run on a server based fired by many scheduled tasks. I understand we'd need to somehow register our "application" (I'm assuming that can be a generic one for our company), but we cannot involve any "user" interaction. These are utility apps. Glancing at the existing sample code for OAuth, they all seem to involve popping up a browser window to get someone to interact with "asking permission" which is exactly what we need to avoid.
We've used IMAP all this time to simply read and parse service based email accounts. I'm not sure I understand why IMAP over a secure connection is "less secure" than a more complex solution. Why take the option away?
On the other hand, the Microsoft Graph API looks significantly more complicated and appears to be OAuth based which, again, seems to involve quite a bit of authentication complexity.
Most REST APIs we've interacted w/ in other .NET console apps use a simple set of API "keys." Why not offer that at least?
As I say, we're looking for a way to write some process that run programmatically to automate a number of operations related to certain mailboxes. IMAP has worked like a charm so far, so we're looking for direct guidance on what to migrate to.
We understand your concerns. While a secure IMAP connection protects the data that's being transported, Basic Authentication exposes your Exchange Online accounts to attack techniques like phishing or brute forcing.
The primary objective of this change is to protect our customers from these threats. In addition, Modern Auth enables admin visibility into app access and enables fine-grained control of these apps.
To answer your question on implementation guidance, there is an existing approach in Graph to achieve exactly what you're looking to do. It's called "OAuth 2.0 client credentials flow". You can read more at https://learn.microsoft.com/en-us/graph/auth-v2-service
(Disclosure - I'm a Senior PM at Microsoft)
I am new to using loopback, and I'm using loopback4 (which I think is referred to as loopback-next)
I have set up my controllers, models & respositories in order to be able to support CRUD operations to mysql, and that is all fine.
I want my loopback application to also connect to an MQTT server, so that I can subscribe to messages from MQTT, and react to those messages by creating entities in my repositories. In addition, I want to be able to have existing controller methods drop messages onto the MQTT (publish)
I am struggling to understand the right way to do this in the loopback eco-system.
I don't think I want to create a Server - because the documentation describes a server as including a listen port. I don't want my loopback application to be a MQTT server. I just want it to interact with one.
Similarly, I don't think this would be an MQTT bridge, or a datasource.
I suspect, what I want is a service. But I'm not certain.
I would appreciate any advice on how to achieve this integration.
Thanks
LB4 is highly extensible and a very good choice for such integrations. What you need in this case is to have a MQTT connector component. You can refer to the documentation for how to create a component in LB4 here and here.
You can refer to an example component implementation for authorization as well for quicker understanding.
At the moment i still only have about 2 months of experience in UI5. i developed a little sample-app, used sap gateway builder to pass my requests to sap backend.
Now my employer asked me to research the possibility to access two different backends (one sap, one nonsap) via odata from the same app. After a little reading and thinking i came to the conclusion that it would be best to access both backends from a single gateway.
Since ive already worked with sap gateway, i wonder if there is a way to access nonsap backends with sap gateway? Are the better options?
Or is my current approach complete wrong and i should think about a whole other way?
It depends on your approach and the non-sap-system:
Is the non-sap-system accesible via Webservices? Then use second data model (e.g. JSON/ODATA) within SAPUI5 by loading data via webservices after initial loadup of your application.
Is the non-sap-system connected to SAP? E.g. via RFC or another technology, then you can read data from the other system during calling your initial Gateway service and simply call your RFC function module in your method.
From my opinion you will not achieve an 'easy' way to read both via one single SAP NetWeaver Gateway.
Not sure why you would want to access a non-SAP oData service via SAP Gateway. On the other hand you may want a router of some sort so that all services are exposed on the same network location and then incoming requests are routed to the appropriate backend for action.
You may also want to "mash-up" the SAP and non-SAP services into some sort of new service. In that case maybe look to some of the API management tools like Apigee to help you achieve that.
I'm at the beginning of trying to understand the requirements for developing a VoIP app. From what I've learned so far, frameworks that allow for communication using SIP/TCP are the best (I don't intend to implement SIP myself).
However, although SIP can be peer-to-peer, its recommended to use an SIP server service. But I'm finding it difficult to locate information about what SIP services are appropriate for an iOS application / what is required from me in terms of setup of the server so that I can concentrate on client-side development.
Any advice would be much appreciated.
You need to figure out your use-cases to decide. A SIP server is like an HTTP server, it will analyse the request URI, the request headers and whatever hints it can see to execute some resource at the backend. Think if you plan to have a user database and authentication. Do you want presence? Do you want voicemail, call transfers, pbx features? Do you want video, audio, IM? Do you want to support arbitrary endpoints? Encryption, NAT traversal, HA? Only then you can think about actual servers and hosting. Many "minimal" configurations will include at least one SIP/media front-end (for NAT/SBC), a SIP/media server (to act on requests), a database server (to store persistent state) and an HTTP server (for config/admin UIs). While there are products that combine some of these into single server, they are generally at least reasonably isolated modules.
So, I'm researching methods for building a client interface for existing EMRs. I've read tons of info on HL7, as well as the various coding schemes, but I'm still really clueless.
For anyone whose worked with an EMR before: is it possible to build a web interface that can use HTTP-POST and HTTP-GET requests to pull/push data to the server database? Or would you have a separate database for the client, say a web application, then use some interface engine like Mirth to communicate between the EMR database and the web application?
A web service API is definitely a way to go. One benefit to this is that you can get https almost out-of-the box for encryption of data in transit.
The way we have configured our EMR is that we have a tcp server accepting incoming hl7 messages from certain IPs which connects directly to our EMR database. This can be beneficial by separating emr and interface processes (You don't have to restart your whole EMR if the interface goes down, for instance).
Another good feature would be to have a token system for pseudo-authentication. This only works if you are going over a secure connection though.
If you aren't into writing your own tcp server (not that hard), an api-based server is probably just as good.
EDIT: What language(s) do you think you'll be using?
Other things that you might run into:
Some applications prefer file drops to direct calls (either url or tcp)
Some vendors will have their own software that sits on a server of yours
Don't forget the ACK.
I don't see why you couldn't do this. You would need to build the web service to handle requests with a specific Uri. When this Uri is called the web service uses the data sent with the request to make changes in the database.
Once you had the web service built, you could build some sort of front-end that displays your information to the user. And makes HTTP-GET and HTTP-POST calls.
There is a lot of flexibililty in what you are trying to do... so go with a plan for sure.
In general though you should be able to accomplish what you need to do by building your own web service and front-end application that is able to manipulate an EMR database.
It really depends on your architecture and requirements.
Architecture 1
If you want your client to be web based, but your client is a separated app from your backend, then the web sends the info using HTTP to your client app server side, and then, that will send info to your EHR backend (another app). That second communication might be written using a standard, that will help you on integrating more systems with your backend in the future. So that interface can be HL7 based, if HL7 v2.x is used, take a look at the MLLP protocol: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=55
This is the most performant way of communicating HL7 data. If you don't want to deal with TCP, there is a proposal for HL7 v2.x over HTTP. HAPI implemented that: http://hl7api.sourceforge.net/hapi-hl7overhttp/
If you don't want to use HL7 v2.x but HL7 v3 (a different standard, not really a version of 2.x) or CDA, you can use HTTP or SOAP.
Architecture 2
But, if you want your client just to be a UI on the user side (browser), HTTP POST will suffice to send info from the browser to the server. That means your EHR is a centralized EHR with a web iu.
In the 1st architectural case, first case you'll probably have multiple client apps (full EMRs apps) and a backend EHR server (centralized backend). On my developments I follow this second architecture.
Also there Mirth might help to manage all the communications between client apps and backend apps. In the 2nd case, using Mirth is nonsense, is just a web application and the client communicates directly with the web server. Of course, you can use Mirth as a web server, but that's not it's role, it is an ESB no a web server.
Hope that helps!