What's MessageTypeId in OCPP request payload - ocpp

In OCPP 1.6, the client (Charging Station) sends a CALL (similar to request in HTTP) to server (Charging Station Management Systems). All CALLs have a strict structure of 4 elements:
MessageTypeId (integer)
UniqueId (UUID, string)
Action (string)
Payload (JSON object containing the arguments relevant to the
Action.)
I have gone through the documentation but I cannot find MessageTypeId. So I want to know whether it is just a random number?
Example request payload:
[
2,// <----- I want to know, where I can find this.
"a7caa7a1-c309-43bd-af3f-b5c1c4f9657e",
"Authorize",
{
"idTag": "${req.body.idTag}"
}
]

MessageTypeId Defines the type of Message, whether it is Call, CallResult or CallError:
MessageType | MessageTypeId | Direction
CALL | 2 | Client-to-Server
CALLRESULT | 3 | Server-to-Client
CALLERROR | 4 | Server-to-Client
You can read more on page 9 of This document .

The OCA is authorized site for getting every single documented information for EV related software like different protocol of OCPP.
Link is as below from which you can download all documentation which contains,
Schema of request and response
Defination
Connection details
Structure of Messaging
Details of when to you which request and its meaning
https://www.openchargealliance.org/downloads/
More over, for your query, once you downloaded there is a document named "ocpp-j-1.6-specification" on where page 10 contains official details
Message type OCPP 1.6 from OCPP 1.6 but from this its not means that CALL will be always from client to server. some request CALL are also there which can be initiated from CSMS(Charging station management system) to CS(Charging station)
Thus below is another documented image for same purpose with newer version of ocpp 2.0.1
Message type OCPP 2.0.1 In here its clearly saying that the request will contains CALL to identifying its a request irrespective of source of generation (Either from CSMS or from CS)

Related

what is " EIO=3&transport=polling&t= " in socket io

"EIO=3&transport=polling&t="
A Full Example :
https://google.com/socket.io/?EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p
here what is use of transport = polling and what t sands for ? and Sid?
nb: if it's not common for all socket io server let me know.
I need a simple explanation for the socket io polling, t and Sid sands for.
If you clone repositories like https://github.com/miguelgrinberg/python-engineio, https://github.com/miguelgrinberg/python-engineio, and https://github.com/socketio/socket.io, then search the codebases, you'll find a handle_request function in server.py, where you may interpret the code and read the code comments. It indicates that https://google.com/socket.io/?EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p may be interpreted as parts of a URL as follows:
https://google.com/socket.io/ is the socket.io scheme/host/path for handling HTTP requests
EIO=3&transport=polling&t=OGkV-snV&sid=szUinCLJL9WftYZ8Bw_p are the query string parameters that are preceded by a question mark ?
query string parameter key EIO is provided to represent the Engine.IO protocol version used by the client, which has a value of 3 in the example, so the Engine.IO web server determines whether that's a compatible version or not
query string parameter key sid is the unique session id (see function generate_id) that is used to store the socket object for that session
query string parameter key transport is provided with a value of polling, so the web server will check that its a valid transport (i.e. either websocket or polling). See here for more info https://socket.io/docs/v3/how-it-works/
I also couldn't determine what query string parameter key t means, even the unit tests only focus on testing the query string parameters EIO, sid, and transport, but not t

Is there a way to set headers for GET requests in KDB?

I'm trying to make get requested with .Q.hg (HTTP get), but I need to edit the request headers to provide API keys. How can I do this?
You can try this function I wrote a few years back for a POC (similar reason - I needed to supply multiple headers). It's based on .Q.hmb which underpins .Q.hp/hg. Please note - it was never extensively tested & there are likely better alternatives out there, but it will perhaps work as a quick solution.
k)req:{[url;method;hd;bd]d:s,s:"\r\n";url:$[10=#url;url;1_$url];p:{$[#y;y;x]}/getenv`$_:\("HTTP";"NO"),\:"_PROXY";u:.Q.hap#url;t:~(~#*p)||/(*":"\:u 2)like/:{(("."=*x)#"*"),x}'","\:p 1;a:$[t;p:.Q.hap#*p;u]1;(4+*r ss d)_r:(`$":",,/($[t;p;u]0 2))($method)," ",$[t;url;u 3]," HTTP/1.1",s,(s/:("Connection: close";"Host: ",u 2),((0<#a)#,$[t;"Proxy-";""],"Authorization: Basic ",.Q.btoa a),($[#hd;(!hd),'": ",/:. hd;()])),($[#bd;(s,"Content-length: ",$#bd),d,bd;d])}
It takes 4 arguments:
Resource URL
HTTP method
Dictionary of headers
Message body as JSON object
Sending a request to a test server..
q).j.k req["https://httpbin.org/get";`GET;("Content-Type";"someOtherHeader")!(.h.ty`json;"blah");""] // no body so pass empty string
args | (`symbol$())!()
headers| `Content-Type`Host`Someotherheader`X-Amzn-Trace-Id!("application/jso..
url | "https://httpbin.org/get"

Smack throws NullPointerException in Roster's presence listener

I'm using Smack with android chatting applications and recently I have updated Smack to version to 4.3.0 and getting some error in fabric. It is a NullPointerException inside of Smack:
Fatal Exception: java.lang.NullPointerException
Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
java.util.concurrent.ConcurrentHashMap.get (ConcurrentHashMap.java:772)
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
org.jivesoftware.smack.roster.Roster.getOrCreatePresencesInternal (Roster.java:388)
org.jivesoftware.smack.roster.Roster.access$1100 (Roster.java:94)
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
org.jivesoftware.smack.AsyncButOrdered$Handler.run (AsyncButOrdered.java:121)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
java.lang.Thread.run (Thread.java:818)
"Use the source, Luke (and study the relevant open standard)" Obi-Wan Kenobi
Smack is open soure, so let us look at the source: One interesting part is
org.jivesoftware.smack.roster.Roster.getPresencesInternal (Roster.java:374)
which reads
Map<Resourcepart, Presence> entityPresences = presenceMap.get(entity);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L374
We also find that presenceMap is declared as follows
private final Map<BareJid, Map<Resourcepart, Presence>> presenceMap = new ConcurrentHashMap<>();
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L168
So it is a ConcurrentHashMap, which matches with the stacktrace. It is obvous that entity above is null, which is the cause of the NullPointerException.
Now we need to walk the call stack up (or down, depening on your point of view), to determine where entity origins from. Here the interesting part is
org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run (Roster.java:1502)
which reads
userPresences = getOrCreatePresencesInternal(key);
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
so enitty is key here. Which is declare and define just a few lines above
final BareJid key = from != null ? from.asBareJid() : null;
Source: https://github.com/igniterealtime/Smack/blob/4.3.0/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1562
So in case from is null, keywill also be null. Which later causes theNullPointerException. Looking at the code, we find that this is caused by a presence XMPP stanza without a from` attribute set.
The question is now if those stanzas are legal in XMPP. To determine that, we need to have a look at the specification. The relevant part is [RFC 6120 ยง 8.1.2.1 4.],1, which states
When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (localpart#domainpart).
So a missing 'from' attribute is generally allowed and is equal to the "account's bare JID".
Now the question is: Are there any presence stanzas specified send from the server to the client which do not have a 'from' attribute? I could not find any while reading the related RFC 6121. And I am not aware when this should ever happen (I possibly could be missing someting). But right now this appears to be a bug in the entity which creates those presence stanzas, which is the used XMPP server implementation.
(What XMPP server implementation do you use?).

Best Practice - API successful response message

My current project API using this response on success:
if it's create -> it will send created object (201)
if it's update -> it will send updated object (200)
if it's delete -> it will send 204 response
Most of recommendation for example http://jsonapi.org/ never said about successful message to shown to user. I've followed their rules to keep returning object or 204 on success
What if I want to show to user alert "Successfully created" or "Successfully updated"?. Should the message come directly from server or client side (type it down or use some locales)?
You should review the RFC 7231, and it's description of 200 OK
The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
POST a representation of the status of, or results obtained from, the action;
PUT, DELETE a representation of the status of the action;
So yes, using the response body to present a representation of an alert to the user is fine.
For 201 Created, the same basic rule applies
The 201 response payload typically describes and links to the resource(s) created.
204 No Content is not similar, for the simple reason that "No Content" refers to the message body; 204 is one of the ways that you can indicate to the client (and intermediary components) that the 0 byte payload is not an error.
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.

REST request type for many to many relationship

Table structure
session
-------------------------
id | name | date
-------------------------
speaker
-------------------------
id | name
-------------------------
session_speaker
-------------------------
session_id | speaker_id
-------------------------
Request methods in place
a) GET /speakers (all speakers)
b) GET /speakers/:id (details on specific speaker)
c) GET /speakers/:id/sessions (list of sessions of a speaker)
Question
What type of request should I make to indicate I need not only the detail of the speaker but also it's sessions, essentially combining results of call (b) and (c) into one.
Also how is it done in real commercial projects? The client makes two calls (b & c) or do they develop another REST endpoint hence combing the results of b & c in a single call?
Or should the client make two requests?
In fact, you could specify as query parameters which fields you want to have within your response payload. Something like:
GET /speakers/someid?fields=firstname,lastname,age,sessions
Another approach (a better one) should be to leverage the header Prefer (see this link for the specification: https://www.rfc-editor.org/rfc/rfc7240) to specify which kind of details you want to have within your response payload:
return=minimal: only the speaker hints
include=sessions: speaker hints and his / her sessions
Here is a sample:
Get /speakers/someid HTTP/1.1
Host: api.example.org
Content-Type: application/json
Prefer: include=sessions
Vary: Prefer,Accept,Accept-Encoding
Irakli Nadareishvili wrote an awesome blog post on this subject: http://www.freshblurbs.com/blog/2015/06/25/api-representations-prefer.html.
Hope it helps you,
Thierry