I'm new to QRadar and having problem of filter QRadar description field in Qradar REST api /siem/offense.
Can anyone suggest me how to filter offense description filed? for example I want to display any offense description start with the word Rule so only the first objective will display.
Data example
{
"description": "Rule_name 1",
"rules": [
{
"id": 104206,
"type": "CRE_RULE"
}
]
},
{
"description": "exampel rule 1\n",
"rules": [
{
"id": 104206,
"type": "CRE_RULE"
}
]
},
If you look at the field explanation. The offense description field is neither filterable nor sortable.
You can try by fetching all the offenses and then filtering required offenses using some script.
Related
Our system needs to return several KPIs grouped in different topics:
Census:
citizens (number of inhabitants)
citizens without any studies
...
Information desk
Phone response time
Mail response time
...
Tax
Online payments
Window payments
...
To my understanding, it would make sense to have an entity for each topic and each KPI being a KeyPerformanceIndicator attribute. eg: This could work similar to:
{
"description": "Census Information system",
"dataProvided": {
"entities": [
{
"idPattern": ".*"
}
],
"attrs":[ //THIS SEEMS AN INTERESTING APPROACH, BUT SADLY ALSO INVALID
{
"name": "citizens",
"type": "KeyPerformanceIndicator"
},
{
"name": "citizens_without_studies",
"type": "KeyPerformanceIndicator"
},
//...
]
},
"provider": {
"http": {
"url": "http://myhost/v2/census"
}
}
}
(TL;DR: "attrs" supports strings only, so can't return complex/data modeled types, like KPI)
Setting this happy idea aside, what it would be a good approach to solve this?
Must each KPI be an entity?
Is NGSI-LD what I'm looking for?
I think your case can be solved in NGIv2. Let my try to explain.
Must each KPI be an entity?
Yes. That's the usual way of modelling KPIs according to the KPIs datamodel. Each KPI is modeled as an entity of type KeyPerformanceIndicator.
Can KPIs be categorized?
Yes. You can use the category attribute to do that.
For instance, you can have an KPI "Online payments" of category "Tax Information" modeled this way:
{
"id": "OnlinePayments",
"type": "KeyPerformanceIndicator",
...
"category": ["taxInformation"],
...
}
Note that category is an array, so a given KPI could belong to more than one category (although in your use case it seems that each KPI belongs to exactly one category so you don't need this feature)
How can I get KPIs that belong to a given category?
You can use regular Orion Context Broker filtering features for that. For instance, to get all KPIs in category taxInformation you could use this key:
GET /v2/entitites?type=KeyPerformanceIndicator&q=category:taxInformation
or this expression in subscriptions:
{
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "KeyPerformanceIndicator"
}
],
"condition": {
...
"expression": {
"q": "category:taxInformation"
}
}
},
...
}
If what you are trying to accomplish is to offer an NGSI interface for your KPI data, you can just create your own adaptor on top of your database that offers a REST interface compliant with NGSI-LD and such service can just return entities of type KeyPerformanceIndicator. Then, you can federate it to a Context Broker with a simple registration i.e. for entities of type KeyPerformanceIndicator. And that's all.
The usage of Linked Data would be recommendable as well, so I would go for NGSI-LD, as it has been officially endorsed by ETSI.
So let's say I have a resources called articles. These have a numeric id and you can access them under something such as:
GET /articles/1 for a specific article.
And let's say that returns something like:
{
"data": {
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON:API paints my bikeshed!",
"body": "A bunch of text here"
}
}
}
Now my question is how to handle a request to GET /articles. I.e. how to deal with the request to the collection.
You see, accessing the body of the article is slow and painful. The last thing I want this REST API to do is actually try to get all that information. Yet as far as I can tell the JSON API schema seems to assume that you can always return full resources.
Is there any "allowed" way to return just the IDs (or partial attributes, like "title") under JSON API while actively not providing the ability to get the full resource?
Something like:
GET /articles returning:
{
"data": [
{
"type": "article_snubs",
"id": 1,
"attributes": {
"title": "JSON:API paints my bikeshed!"
}
}, {
"type": "article_snubs",
"id": 2,
"attributes": {
"title": "Some second thing here"
}
}
]
}
Maybe with links to the full articles?
Basically, is this at all possible while following JSON API or a REST standard? Because there is absolutely no way that GET /articles is ever going to be returning full resources due to the associate cost of getting the data, which I do not think is a rare situation to be in.
As far as I understand the JSON API specification there is no requirement that an API must return all fields (attributes and relationships) of a resource by default. The only MUST statement regarding fields inclusion that I'm aware of is related to Sparse Fieldsets (fields query param):
Sparse Fieldsets
[...]
If a client requests a restricted set of fields for a given resource type, an endpoint MUST NOT include additional fields in resource objects of that type in its response.
https://jsonapi.org/format/#fetching-sparse-fieldsets
Even so this is not forbidden by spec I would not recommend that approach. Returning only a subset of fields makes consuming your API much harder as you have to consult the documentation in order to get a list of all supported fields. It's much more within the meaning of the spec to let the client decide which information (and related resources) should be included.
The "attributes" object of a JSON-API doc does not need to be a complete representation:
attributes: an attributes object representing some of the resource’s data.
You can provide a "self" link to get the full representation, or perhaps even a "body" link to get just the body:
links: a links object containing links related to the resource.
E.g.
{
"data": [
{
"type": "articles_snubs",
"id": "1",
"attributes": {
"title": "JSON API paints my bikeshed!"
},
"links": {
"self": "/articles/1",
"body": "/articles/1/body"
}
},
{
"type": "article_snubs",
"id": "2",
"attributes": {
"title": "Some second thing here"
},
"links": {
"self": "/articles/2",
"body": "/articles/2/body"
}
}
]
}
I am reverse engineering an app that sends queries to
SOMESERVERNAME.analysis.windows.net/public/reports/querydata via an HTTP POST of an JSON-structured query.
Some initial lines of a sample query are at the end of this message.
I can't find any documentation on this anywhere. I don't know if this is some secret API or what. I ultimately would like to just ignore the aggregations altogether and just dump the raw data, which seems to sit in some flat-file type container on the back-end, but without some API documentation I'm stuck with just re-running the super basic handful of queries I've been able to intercept.
Note: this app is an embedded analytics page created with PowerBI, but the only REST API I can find for PowerBI has nothing to do with querying, but just basic object management.
Thanks!
{
"version": "1.0.0",
"queries": [
{
"Query": {
"Commands": [
{
"SemanticQueryDataShapeCommand": {
"Query": {
"Version": 2,
"From": [
{
"Name": "s",
"Entity": "Sheet1"
}
],
"Select": [
{
"Aggregation": {
"Expression": {
"Column": {
"Expression": {
"SourceRef": {
"Source": "s"
}
},
"Property": "Total"
}
},
"Function": 0
},
"Name": "Sum(Sheet1.Total)"
}
],
"Where": [
{
"Condition": {
"In": {
"Expressions": [
{
"Column": {
"Expression": {
"SourceRef": {
"Source": "s"
}
},
"Property": "Year"
}
}
],
"Values": [
[
{
"Literal": {
"Value": "'2018'"
}
}
]
]
}
}
},
............
I have built a client that scrapes data off a specific Power BI report using the same API, but probably you'll be able to adapt it to your use case. Maybe we can even abstract the code into a more generalized Power BI client!
Having tinkered with the API for two days, I realised that there are many ways the data can be formatted:
"nested"/multidimensional data can be unflattened, flattened by 1 degree, etc.
a primary "table" of a result dataset (in data.PH) can reference others (in data.SH)
The basics are as follows:
A dataset is structured like a multidimensional table, with cells containing values.
In a set of cells, the first always has a field S that contains the schema of its and all subsequent cells.
The schema maps a field of each cell's object with a selection from your query, e.g. the G0 field with the queried column age.
My client seems to work only with a specific type of query (SemanticQueryDataShapeCommand), a specific nr of dimensions and a specific column marked as primary (via Binding.Primary). But maybe that helps! https://github.com/derhuerst/fetch-bvg-occupancy/blob/1ebb864b1ff7130f9d2f0ab031c6d78bcabdd633/lib/parse-dataset.js
The only documented way to use this API is through the ADOMD.NET or OleDb provider.
If you want to send a DAX/MDX query and retrieve data programmatically, there's a sample of how to front-end the service with a simple REST API here.
I'm using the graph search method of the Microsoft Academic API to retrieve papers by ID using the following query:
{
"path": "/paper",
"paper": {
"type": "Paper",
"id": [2557283755],
"select": [
"PublishYear",
"CitationCount",
"OriginalTitle",
"NormalizedTitle",
"DOI"
]
}
}
The issue I'm having is that for some papers the response is completely empty, even though when I lookup the paper through the user interface, it has full metadata. For example, trying to retrieve this paper through the API yields
{
"Results": [
[
{
"CellID": 2557283755,
"PublishYear": "",
"CitationCount": "",
"OriginalTitle": "",
"NormalizedTitle": "",
"DOI": ""
}
]
]
}
while for a different paper the response is correct:
{
"Results": [
[
{
"CellID": 2112796928,
"PublishYear": "1998",
"CitationCount": "135",
"OriginalTitle": "Gradient-based learning applied to document recognition",
"NormalizedTitle": "gradient based learning applied to document recognition",
"DOI": "10.1109/5.726791"
}
]
]
}
Does anyone have any experience with this? To me it looks like an error in the database, but I wanted to make sure it's not something related to my query. Thanks!
The issue is caused by data version difference. The version of the academic graph data set used by graph search method might not be the same as that of Microsoft Academic portal https://academic.microsoft.com. We are deploying a new data pipeline to make the version difference as small as possible.
I have some Java REST APIs which will be invoked via JIRA Webhook configuration.
Now, when JIRA webhook is invoking REST API, there are large no. of custom fields (like customfield_17270) which contain useful data.
For example, I have configured "Create Issue" event in JIRA webhook i.e. whenever any issue will be created in JIRA, my REST API will be invoked. While creating issue in JIRA, for example, there is a field named "Issue Title" whose value is "XXX". In JSON payload, ideally key-value pair should be "Issue Title":"XXX" but it is like "Custom_Field109":"XXX".
Now the problem is how to map this dynamic JSON to Java Object.
Is there anyone who has faced similar problem.
Each time you receive the webhook, you'll need to map each custom id (e.g. customfield_10070) to it's name by querying the field JIRA REST API at GET: /rest/api/2/field
...which will give you something like this:
[
{
"id": "issuetype",
"name": "Issue Type",
"custom": false,
"orderable": true,
"navigable": true,
"searchable": true,
"clauseNames": [
"issuetype",
"type"
],
"schema": {
"type": "issuetype",
"system": "issuetype"
}
},
{
"id": "customfield_10070",
"name": "FAQ Necessary?",
"custom": true,
"orderable": true,
"navigable": true,
"searchable": true,
"clauseNames": [
"cf[10070]",
"FAQ Necessary?"
],
"schema": {
"type": "string",
"custom": "com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons",
"customId": 10070
}
},
...
]
You should then easily be able to iterate over the fields from the webhook JSON and map the custom field id to its display name.
I was able to discuss this issue with JIRA internal team and they provided me custom fields mapping to their JIRA display name.
Basically, when we receive Json keys like Custom_field109 then it means 109 is internal database id for this attribute.
Now, based on given mapping, I parsed JSON to get required keys and then through Jackson library, I was able to map JSOn to Java.