Schema at producer side:
{
"type":"record",
"name":"ClientIdentifier",
"namespace":"namespace1",
"fields":[
{
"name":"data",
"type":"string"
}
]
}
Schema at consumer side:
{
"type":"record",
"name":"ClientIdentifier",
"namespace":"namespace2",
"fields":[
{
"name":"data",
"type":"string"
}
]
}
Both have different namespaces. How to make them compatible with each other.
I am using encoders and decoders present within generated avro classes for serialization and deserialization.
Also, I am using #KafkaListener annotation in consumer in spring boot.
I found that on using the encoder within the Avro Generated Message, we can not decode back if we have a different namespace at the consumer side since it utilizes namespace's value internally. The only option is to use GenericDatumWriter on the producer side and GenericDatumReader on the consumer side.
Related
I have a gateway fromKhomp manufacturer which delivers packages in the following format (SenML):
message: [
{
"bn": "000D6FFFFE642E09",
"bt": 1611339204
},
{
"n": "model",
"vs": "nir21z"
},
{
"n": "Geladeira Temp",
"u": "Cel",
"v": 4.0
}
When I connect to the Thingsboard platform, the internal GW/Parser breaks as an array before the Input in the Root Rule Chain, and threats as individual packets, but since the first position in this array corresponds to the device ID (MAC) I need to have the whole message to be parser in a script. Does anyone know a way to get the information before the GW parses the message?
If you're using Thingsboard CE then I think you will need to first forward the data to a middleware service to restructure the payload. If you are familiar with AWS Lambda you can do it there.
It would just be a simple script that takes an input payload, restructures, and then forwards to your Thingsboard deployment.
If you're using Thingsboard PE then you can use Integration/Data Converters to do this.
I want to modify the response of hasura fetch query.
the current response is this:
{
"data": {
"ids": [
{
"id_object": {
"id": 33102
}
},
{
"id_object": {
"id": 33104
}
}
]
}
}
And I want to remove "id_object" and want just array of id's like this:
{
"data": {
"ids": [
{
"id": 33102
},
{
"id": 33104
}
]
}
}
A GraphQL server exposes an exact set of operations and the shape of the allowed responses for those operations. When interacting with any GraphQL server (Hasura or otherwise), it is therefore not possible to to arbitrarily modify the shape of the returned data.
You're free to map it into a new form when you receive the data on the client side.
If you really need the server itself to be able to respond using this shape, you'll need to extend Hasura's schema to be able to specifically support this query pattern.
There are a number of different ways that you could accomplish this:
You could write a custom Hasura Action
You could expose this query from your own GraphQL server and then stitch it together with Hasura using Remote Schemas
You could use a Postgres View or Function to shape the data as required and expose it as a new operation
I am returning MOCK JSON response for GraphQL query response in Apollo iOS client. But Apollo client is not parsing the MOCK json content.
Error: __typename missing in mock response.
I found the solution after spending some time on Apollo Client framework iOS.
Mock JSON response must contains __typename key-value in each structure inside it. So that Apollo client decoding functions can decide the corresponding struct models for the response.
{
"data": {
"summary": {
"__typename": "AccountSummaryResponse"
"accountSummary": [{
"token": "45454"
"type": "club"
"__typename": "AccountSummary"
},
{
"token": "4344"
"type": "clubA"
"__typename": "AccountSummary"
}
]
}
}
}
You will get the __typename value from API.swift automated generated file by Apollo Code-gen.
Imagine you are working under following circumstances:
You have REST API modules with API documentation generated into swagger-ui.html
Possible HTTP status codes for endpoints are documented well via io.swagger.annotations.* on controller method level for each endpoint.
In case of some error state (4XX or 5XX) application replies with ErrorResponseDTO with structure like
"ErrorResponseDTO": {
"type": "object",
"properties": {
"errorCode": {
"type": "integer",
"format": "int32"
},
"message": {
"type": "string"
}
}
}
Application have tens of errorCodes (within range like 1 - XX and please consider them as a legacy definiton without an easy way to change them).
List of errorCodes is relevant for the whole application so you prefer to keep their definiton list/table in overall API documentation rather then maintaining errorCodes definiton for each API endpoint separately.
Now you are looking for an effective way how to document these application error codes into API contract.
The approach of including a list of errorCodes with codes description into generated swagger-ui.html seems like a better way to keep API documentation up to date instead of having static and handwritten codes definition table attached in Markdown format in some Readme file.
Would you please have any recommendation how to document various codes which your applications produce?
Do you follow some specific good practice in this topic?
Thank you in advance.
Meanwhile within a small internal dev team and with frequent API extensions there can be used generated swagger-ui with included error codes:
#Bean
public Docket swaggerSettings() {
ApiSelectorBuilder builder = new Docket(DocumentationType.SWAGGER_2)
.apiInfo(
new ApiInfoBuilder()
.title("Response errorCodes table")
.description(RestResponse.generateErrorsDocumentation().toString())
.build()
)
...
.select();
return builder.apis(RequestHandlerSelectors.withClassAnnotation(Api.class))
.paths(PathSelectors.any())
.build()
.useDefaultResponseMessages(false);
}
Fiware-cygnus documentation mentions that it is based on Apache Flume. However, it is not clear whether I can use native Flume sinks to persist events arriving from Orion Context Broker. Is this something I can easily do, with little (or ideally zero) coding? If not -- would be good to know why (and whether this can be supported going forward). Thanks!
You can use native Flume sinks by simply configuring them. Nothing has been changed in Cygnus in terms of configuration management, thus you can configure a Orion-like sink or a native one.
Nevertheless, there are differences between Orion-like and native Flume sinks.
The first one is the Orion-like sinks store the relevant data with certain structure, and the Flume native sinks will store the notified raw data. I mean, if you receive a Json-based notification such as:
{
"subscriptionId" : "51c0ac9ed714fb3b37d7d5a8",
"originator" : "localhost",
"contextResponses" : [
{
"contextElement" : {
"attributes" : [
{
"name" : "speed",
"type" : "float",
"value" : "112.9",
"metadatas": []
},
{
"name" : "oil_level",
"type" : "float",
"value" : "74.6",
"metadatas": []
}
],
"type" : "car",
"isPattern" : "false",
"id" : "car1"
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
]
}
OrionHDFSSink will store something like:
{"recvTimeTs":"1429535775","recvTime":"2015-04-20T12:13:22.41.124Z","fiware-servicePath":"4wheels","entityId":"car1","entityType":"car","attrName":"speed","attrType":"float","attrValue":"112.9","attrMd":[]}
But a native HDFS sink (or any other one) will persist the entire notified json.
The second main difference if the handling of the notified fiware-service and fiware-servicePath. Cygnus's sinks are able to deal with these values in order to map the notified data into specific data structures (folders, databases, tables, resources, queues...). This is very important for multi-tenancy purposes.
Third, Cygnus adds sinks for storages not covered by native Flume, such as CKAN, STH, MongoDB, MySQL or DynamoDB.
There are many other differences:
The usage of the Grouping Rules.
The Management Interface.
OAuth2 authentication, which is the official FIWARE's mechanism.
...