Member since
11-16-2015
911
Posts
671
Kudos Received
249
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1326 | 09-30-2025 05:23 AM | |
| 1730 | 06-26-2025 01:21 PM | |
| 1583 | 06-19-2025 02:48 PM | |
| 1658 | 05-30-2025 01:53 PM | |
| 14603 | 02-22-2024 12:38 PM |
05-10-2019
06:18 PM
1 Kudo
To address your comment below, I missed the part where you want to call the outgoing field "color". Change this line (8): "$": "colorsLove[].&2" To this: "$": "colorsLove[].color"
... View more
05-10-2019
04:27 PM
1 Kudo
This Chain spec will add the hardcoded value 20190905 into the array (after removing empty values): [
{
"operation": "shift",
"spec": {
"color_*": {
"": "TRASH",
"*": {
"$": "colorsLove[].&2"
}
},
"*": "&"
}
},
{
"operation": "shift",
"spec": {
"colorsLove": {
"*": {
"#20190905": "colorsLove[#2].date",
"*": "colorsLove[#2].&"
}
},
"*": "&"
}
},
{
"operation": "remove",
"spec": {
"TRASH": ""
}
}
] You should be able to replace "#20190905" with a NiFi Expression Language statement, maybe something like: "#${now:toNumber():format('yyyyddMM')}" ... but I didn't try that part.
... View more
05-07-2019
01:30 PM
1 Kudo
If you are not obtaining keys from the database, not using fragmented transactions, and not rolling back on failure, then you should see the failed flow files in a batch being routed to the failure relationship. If you must configure the processor differently, then the flow files will be treated as a single transaction. In that case, in order to handle individual failures you'll want to not use batches, meaning set PutSQL's Batch Size property to 1.
... View more
05-02-2019
08:51 PM
1 Kudo
I don't think your desired output is valid JSON, as the root object only has an array in it, not a key/value pair. If you want a key in there (let's call it root) the following spec will work in JoltTransformJSON: [
{
"operation": "shift",
"spec": {
"*": "root.[]"
}
}
] Otherwise if you just want to add braces around the array, you can use ReplaceText, replacing the entire thing with {$1}
... View more
04-19-2019
02:21 AM
The JOLT DSL takes a lot of practice, but once it clicks, it's like seeing the Matrix lol. I'm no expert but I've put my time in 😉
... View more
04-18-2019
07:15 PM
1 Kudo
Try JoltTransformJSON with the following spec: [
{
"operation": "shift",
"spec": {
"*": "TrackingRequestInformation.&"
}
},
{
"operation": "default",
"spec": {
"TrackingRequestInformation": {
"TrackingRequestFirstIp": null,
"TrackingRequestLastIp": null,
"TrackingRequestCreationTime": null,
"TrackingRequestCreationDate": null,
"TrackingRequestTrackingNumber": null,
"TrackingRequestFirstCityName": null,
"TrackingRequestFirstIpLat": null,
"TrackingRequestFirstIpLong": null,
"TrackingRequestFirstIpCountryName": null,
"TrackingRequestFirstIpCountryCode": null,
"TrackingRequestFirstIpPostalCode": null,
"TrackingRequestFirstIpGeoLocation": null,
"TrackingRequestLastCityName": null,
"TrackingRequestLastIpLat": null,
"TrackingRequestLastIpLong": null,
"TrackingRequestLastIpCountryName": null,
"TrackingRequestLastIpCountryCode": null,
"TrackingRequestLastIpPostalCode": null,
"TrackingRequestLastIpGeoLocation": null
},
"DataSourceInformation": {
"DataSourceUuid": null,
"DataOwnerUuid": null,
"RecordUuid": null
}
}
}
] This spec moves the tracking data into TrackingRequestInformation, adds a default DataSourceInformation object, and adds any fields that aren't in the original input, seems to output what you describe above.
... View more
04-09-2019
07:22 PM
1) I believe TransformXML is more flexible in terms of structural transformation as it leverages the full power of XSLT. However the XML-to-JSON XSLTs I've seen sometimes have limitations (inline comments can be a problem, e.g.). 2) I'm not sure which would be faster per se, probably depends on how much data, what kind of transformation(s) are performed, etc. Also I think TransformXML reads the entire XML input into memory, so for large XML files you may risk running out of memory. ConvertRecord's record readers read in a single record at a time IIRC. 3) It doesn't seem like you want to convert anything to Avro, are you asking how to see the record schema? Internally we have our own RecordSchema representation, but when we write out to a flow file attribute (for example), we use Avro's schema format (even if the data is in CSV, JSON, XML, etc.). To see the schema, set your RecordSetWriter to write the schema to the avro.schema attribute, then you can inspect the flow file's attributes from the UI and see the Avro schema. 4) ConvertRecord only changes the format of the input (CSV to JSON, e.g.), it doesn't really do any transformation of the records (although technically you can configure it to add or remove fields). If you're doing any actual transformation of data (uppercasing field names, changing "F" to "Female", etc.) then you can use JoltTransformRecord, UpdateRecord, etc. The key is that all record-based processors will do format conversion for you, so you only need ConvertRecord if all you want is to change the format of the data. Otherwise the other record processors do their thing (like PartitionRecord groups records by value) but will also convert the format, depending on which Reader and Writer you configure. Does that make sense?
... View more
04-09-2019
05:58 PM
This is an open issue (NIFI-4957), I pinged the original author/contributor to get the status of it, if he is not actively working it I can take a look at adding the capability.
... View more
04-09-2019
02:54 PM
1 Kudo
You can use UpdateRecord for this, but make sure you have the additional fields in your writer's schema. Alternatively you can use JoltTransformJSON with the following spec: [
{
"operation": "default",
"spec": {
"attributes": {
"id": "12233",
"map": "Y"
}
}
}
]
... View more
04-08-2019
06:40 PM
You can also try JoltTransformRecord, using the JOLT DSL you can choose which fields you want from the input (and where to put them in the output). As a record-based processor, you can use the XMLReader and JSONRecordSetWriter and it will do the conversion for you.
... View more