Azure Graph API Event filter not finding events, always blank - azure-ad-graph-api

I am trying to filter events using the transactionID that I used to create the event, but when I filter, it always comes up blank
https://graph.microsoft.com/v1.0/users/b3255f69-88be46aad08c/calendars/AAMkADE0NzMyZDcwLTAxOTg1AAA=/events?$filter=singleValueExtendedProperties/Any(ep: ep/id eq 'Integer {66f5a359-4659-4830-9070-00047ec6ac6e} Name transactionid' and cast(ep/value, Edm.Int32) eq 51686)

It is not possible to filter the events by transaction Id .
I tested the same by filtering creation date time and transaction Id. For creation date time it succeeded and transaction Id it failed as it's not supported.
TransactionId
https://graph.microsoft.com/v1.0/me/calendars/{id}/events?$filter=transactionId eq null
CreationDateTime
https://graph.microsoft.com/v1.0/me/calendars/{id}/events?$filter=createdDateTime eq 2021-11-04T15:08:27.9058547Z

Related

OData Query to Only Return State Changes from Azure Devops

I have an OData Query that I am using to pull data into PowerBI that I am trying to make more efficient. I am doing a report from Azure DevOps and pulling data in from the WorkItemRevisions resource. Currently, I am pulling all the data for a Work Item and then filtering in PowerBI to only get when the State has changed. I would like to move this filtering to the Odata query so that I can minimize the data that I am pulling into the report.
Currently, I have a query like the following (simplified example used for this question)
https://analytics.dev.azure.com/{Organization}/{Project}/_odata/v3.0-preview/WorkItemRevisions?
$select=Revision,WorkItemId,WorkItemType,Title,State,ChangedDate,LeadTimeDays,ParentWorkItemId
How can this be updated so that only Revisions where the State has changed (from New to Active, Active to Done, etc) are returned?
How can this be updated so that only Revisions where the State has changed (from New to Active, Active to Done, etc) are returned?
I am afraid that OData Query could not perfectly achieve what we need.
There is a feature Revisions/any(r:r/state eq '{state}') to filter the work item has a set state in the past.
For example:
https://analytics.dev.azure.com/<Organization>/<Project>/_odata/v2.0//WorkItems?
$filter=State eq 'Closed' and Revisions/any(r:r/State eq 'Active')
This query is similar to a Work Item query that uses the Was Ever operator.
As I said, this may not be a perfect solution. That because it can only filter whether the work item has ever had a specified states, but cannot accurately determine the states of the work item must be from New to Active, Active to Done. If we change the state of the workitem from Active to Resolved, then change it from Resolved to Closed. Then this work item will appear in the query results.
In addition, even if you use the UI query, we cannot accurately query the result of the work item status changing from A to B. To achieve this goal, we need to use REST API.
So, we could use the feature Revisions/any(r:r/state eq '{state}') to reduce the data pulled into the report to a certain extent.
You can use below query to achieve what you want.
/_odata/v4.0-preview/WorkItemRevisions?&$apply=filter(((WorkItem/WorkItemType
eq 'Bug' or WorkItem/WorkItemType eq 'Product Backlog Item') and
((WorkItem/ChangedDate ge 2022-10-05Z and WorkItem/ChangedDate le
2022-11-04Z) or (WorkItem/CreatedDate ge 2022-10-05Z and
WorkItem/CreatedDate le 2022-11-04Z))))/groupby((WorkItemId,State),
aggregate(ChangedDate with min as MinChangedDate))
To filter the group by data you need to encapsulate it under $apply as it is shown above.
Above URL will return all states and their changed dates for Bug and PBI Work Item types which are added or updated with a given date range.
Hope it helps!
if you are able to use Analytics Views instead of OData, there is a dedicated field available in Analytics Views Fields setting called "State Changed Date"

How correctly make REST API request to get complete orders between a date range in Magento 2

I want to get complete orders between a date range using Magento 2 REST Api. So request looks like:
/rest/V1/orders?searchCriteria[filterGroups][0][filters][0][field]=status&searchCriteria[filterGroups][0][filters][0][value]=Complete&searchCriteria[filterGroups][0][filters][0][conditionType]=eq
Now I want get it in specific period. I found that Magento api has "from" and "to" fields but I always confused in searchCriteria filter index. Can anybody complete my request? Thanks
You will get complete orders between a date range by using the conditions from and to.
This API will get you the orders between the two dates:
http://<magento_host>/rest/V1/orders?
searchCriteria[filter_groups][0][filters][0][field]=created_at&
searchCriteria[filter_groups][0][filters][0][condition_type]=from&
searchCriteria[filter_groups][0][filters][0][value]=from_date&
searchCriteria[filter_groups][1][filters][0][field]=created_at&
searchCriteria[filter_groups][1][filters][0][condition_type]=to&
searchCriteria[filter_groups][1][filters][0][value]=to_date
Example:
http://<magento_host>/rest/V1/orders?
searchCriteria[filter_groups][0][filters][0][field]=created_at&
searchCriteria[filter_groups][0][filters][0][condition_type]=from&
searchCriteria[filter_groups][0][filters][0][value]=2016-07-01 00:00:00&
searchCriteria[filter_groups][1][filters][0][field]=created_at&
searchCriteria[filter_groups][1][filters][0][condition_type]=to&
searchCriteria[filter_groups][1][filters][0][value]=2018-07-01 00:00:00
The above API will get you the orders between a by using created_at timestamp.
For an example also see the Magento Docs.

How to get past/ended public events from facebook using graph api/FQL?

I tried using the since and until parameters to get past events but it doesnt seem to work. The results from using since and until parameters give only events that have an end date in the future and a start date within the specified time limit. But however i would like to retrieve a list of all public events within the specified limit irrespective of whether it is still active or not. Is this possible?
Thanks for your help
You can use FQL for that:
select eid, name, start_time from event where creator = {page_id} and start_time >= "2014-05-01T00:00:00+0200" and start_time <= "2014-05-31T23:59:59+0200"
Make sure that {page_id} is a valid Page ID (or User ID). See https://developers.facebook.com/docs/reference/fql/event/ as reference.

Pagination logic in Mainframe CICS

Here is my requirement.
Front (Client) end will do a search based on predefined conditions (for instance: customer id, account number, first name, last name, etc). I need to get the data corresponding to this request from a db2 database and send it back to them (Server). We use CICS channels and containers to pass requests and responses between the Client and Server.
Front end needs the data ordered by: Receive date descending, Customer id Ascending, Account number Ascending. Data are fetched in pages of 500 records. For example, if for a search request from front end would retrieve 50,000 records from the db2 database, we need to return this data in 500 record "pages". For pagination concept, we use the field security deposit number which is primary key to our database but the sorting order is not based on this field.
I would like to know whether we can use scrollable cursor logic in CICS to implement pagination.
Please note that I do not prefer to go for internal array bubble sort to send the data in response as it would degrade performance. I like to do it via query logic.any thoughts?
Example (Initial Front end input request):
Customer id : A
First time request (To identify whether it is first time or next or previous request for pagination)
First security deposit number : 0
Last security deposit number : 0
Since this is first time request, both this field will be having zero from front end and we need to retrieve records from database based on condition of security deposit > 0
Db2 database:
There are 700 records for this criteria
Mainframe response for first time:
We will send the first 500 records
Front end will then send request for getting next set of records which will contain:
Customer id: A
Next request
First security deposit numbr: 0
Last security deposit number : 17980
So for this detail, if I query my datbase based on security deposit number > 17980, it may result in duplicate records listing in the screen once again since our sorting order in database is not based on security deposit number
How to impelement this logic??
Many Client/Server applications in an IBM Mainframe environment involve psuedo conversational CICS transactions.
If you are using CICS in psueudo conversational mode it
is not possible for the Server to hold cusors when it RETURNs to the Client. Therefore scrollable cusors
are of little use in this environment. So to answer your basic question: No scrollable cursors cannot be used here.
The "trick" here is to create an SQL predicate in the Server that is restartable. It will then pick up rows in the correct order from any given
stating point. When the Client calls your Server it must pass all of the positioning information to your Server.
Typically, on a first call from a Client all of the positioning values are set to cause the cursor to
position itself starting with what must be the the first row. The Server then pulls in a "page" worth of data
and returns it to the Client. On the next page forward request the Client sets these positioning values to
the last row it displayed and calls the Server for the next "page" of data.
In your situation I would assume that the page forward cursor would look something like this, all the
variables prefixed with RESTART... are what the Client must provide to the Server to start the cursor
in the correct position.
DECLARE CURSOR Page-forward FOR
SELECT Receive_Date, Customer_id, Account_Nbr, Security_Dep_Id
FROM Table_Name
WHERE ( (Receive_Date < :RESTART-RCV-DT)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id > :RESTART-CUSTOMER-ID)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr > :RESTART-ACCT-NBR)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr = :RESTART-ACCT-NBR AND
Security_Dep_Id > :RESTART-SEC-DEP-ID))
ORDER BY 1 DESC, 2 ASC , 3 ASC, 4 ASC
For the initial call the Client would have passed something like '9999-12-31' as the RESTART-RCV-DT, zero
for the RESTART-CUSTOMER-ID, RESTART-ACCT-NBR and SEC-DEP-ID (assuming these are all numeric). If you look at
the cursor predicate carefully you can verify that there cannot be any rows prior to these values - therefore this
will return the first page of data. If the Client needs to page forward after this, it must tell the Server to start
with the next row after the last one it received. To do this it would populate the RESTART... variables with
the values from the last row on the page it just
displayed. This process will drive the cursor selects forward one page at a time.
When paging up, the process is reversed (you will need a second cursor to support this, and the Client needs to tell you which direction to page: Forward or Back). The Client
will need to populate the RESTART variables with the first row it recieved from the Server. The trick
for the Server on a page up request is to return the data
to the Client in reverse order. You may have to populate the data page passed back
to the Client in reverse order (ie. put the first row retrieved into the last row of the paging area shared between
the Client and the Server). The page backward cursor would look something like:
DECLARE CURSOR Page-backward FOR
SELECT Receive_Date, Customer_id, Account_Nbr, Security_Dep_Id
FROM Table_Name
WHERE ( (Receive_Date > :RESTART-RCV-DT)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id < :RESTART-CUSTOMER-ID)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr < :RESTART-ACCT-NBR)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr = :RESTART-ACCT-NBR AND
Security_Dep_Id < :RESTART-SEC-DEP-ID))
ORDER BY 1 ASC, 2 DESC , 3 DESC, 4 DESC
As has been pointed out in other answers, this type of paging process does not manage or detect concurrent
updates to the database that may occur duing paging transactions. That is another topic for another day...
Developing Restartable Cursors
The the key to building a paging Server is to develop a cursor that is restartable from a set of values received
from a Client transaction. This leaves control of cursor positioning and direction with the Client.
It also means the Client must receive all critical positioning data from the Server even though
the Client might not actually
use these data for any other purpose (e.g. From your question I got the impression that the Client may not require
the Security Deposit Id except to supply as a positioning parameter for your Server)
To build a paging Server you need to know
what the required sorting order of the data are (e.g. Receive Date Descending then Customer Id Ascending then
Account Number Ascending).
You also need know the set of data that uniquely identify a row
returned by the cursor. In your case that would be the Security Deposit Id (this is the primary key for the
table you are selecting from so it must be unique for each and every row in that table). Knowing this you then build a
cursor predicate (the stuff in the WHERE clause) that will return data needed by the Client in the required sort order that
also includes
the full positioning key (i.e. Security Deposit Id). In the event that two or more returned rows may contain identical data if
the final positioning key were elimiminated makes it important that the positioning key be included as a sort condition.
It doesn't matter if it is ascending or descending, but it needs to be included on the sort to ensure consistent
order of data retrieval.
A fairly simple formula may be followed to build the predicate for a restartable cusor needed to
support paging Servers. Basically this is a cascade of "OR" clauses connecting a series of "AND" clauses
that become progressively more selective following the sort order required by the Client and end up with the positioning
key.
To see how this works consider how the query for your Server might be developed...
Start with the column from the sort order that changes least often...
SELECT ...
FROM ...
WHERE Receive_Date < restart value
This will retrieve all rows prior to the specified restart Receieve date regardless of what the other
column restart values are (e.g. Customer ID's can range from minimum to maximum values, as long as the Receive Date
is less than any Receive Date "seen" so far). Since this column only changes value after all subortinate sort columns values
have been exausted you can be sure that this does not pick up any rows prior to the full restart key.
But what about those rows that occur on the same date as the restart request but have a
larger Customer Id? These can be picked up with....
SELECT ...
FROM ...
WHERE Receive_Date = restart value AND
Customer_id > restart value
What about those where the Receive Date and Customer Id are the same as the restart key but have
a larger Account Number? These can be picked up with...
SELECT ...
FROM ...
WHERE Receive_Date = restart value AND
Customer_Id = restart value AND
Account_Nbr > restart value
Continue this pattern until the full restart key has been processed. Notice that the inequality
signs are determined by the sort order. Use < when the column is sorted Descending and > when Ascending.
Also notice that the SELECT and FROM clauses
are exactly the same for each query - which means you can put them all together using OR conjuctions...
SELECT Receive_Date, Customer_id, Account_Nbr, Security_Dep_Id
FROM Table_Name
WHERE ( (Receive_Date < :RESTART-RCV-DT)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id > :RESTART-CUSTOMER-ID)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr > :RESTART-ACCT-NBR)
OR (Receive_Date = :RESTART-RCV-DT AND
Customer_Id = :RESTART-CUSTOMER-ID AND
Account_Nbr = :RESTART-ACCT-NBR AND
Security_Dep_Id > :RESTART-SEC-DEP-ID))
ORDER BY 1 DESC, 2 ASC , 3 ASC, 4 ASC
There you go... a restartable cursor for forward paging. Construction of the cursor for backward paging follows a similar pattern, just flip the
sort orders and repeat.
A simplistic approach: Write your SQL to retrieve data according to your criteria, in the sort order you specify. Then only retrieve the keys to the rows you want. Save the keys somewhere you will have access to upon subsequent invocations of your transaction. Look into multi-row select in DB2. Also understand pseudo-conversational programming techniques in CICS.
And now we get to the design implications Bill Woodger mentions, that you do not specify in your question, and which are the reason I'm just hitting the high points of a simplistic approach.
If changes to your result set occur between one invocation and the next, your results will not reflect those changes. You must decide if this is important.
You mention a "front end" but do not specify what it is. If it is a BMS application, you may be able to save the keys in your commarea or in a container. If your front end is a distributed application invoking your transactions via CICS Web Services or CICS Web Support or MQ or raw sockets or whatever, you must design a mechanism to store those keys such that you can uniquely retrieve them — perhaps by sending a contrived key back to the distributed application which it must supply upon subsequent invocations. Then you must have some process to clean up your key store.
Creating a solution to your problem that is unique in your IT shop is not something to be done in isolation. You must involve others who will be tasked with maintaining your application, there may be a group external to your project tasked with making such decisions, there may be infrastructure issues with your solution.
So this isn't so much as an answer to your question as it is an elaboration upon why you may not get an answer, or at least the answer you seem to desire.

Salesforce: trigger on related list

Suppose I have two objects
1.Account- standard object[it has a field name Status_c which is a picklist having value inprogress and closed]
2.Client_c - custom object[it also have same field name Status__c which is a picklist having value inprogress and closed]
and Client__c has lookup to Account name which means Account has a related list of client object .
My question is :
I want to write a trigger where if I put account status to "closed" I can not put client status to "closed",it should throw an error message on client object or if I put client status to closed I can not put account status to closed vice versa.
Can any one please help me to write a trigger on this??
Conceptually, I think what you are looking to do is set up Validation Rules on both of those objects. Your validation rule on Client_c should be pretty simple: TEXT(Status_c) == 'Closed' && TEXT(Account_c.Status_c) == 'Closed'
The more interesting piece is how you handle making sure none of your related items are Closed when you move the Account to Closed. I tend to prefer creating a field on the Account that keeps track of the status of the related items (checkbox) that basically tells me whether it is valid for me to change my status or not. In this case, the validation rule becomes pretty simple. In order to set that boolean value, I end up using a Trigger on Client__c that basically just grabs all the Accounts when a Client is being modified in the batch (taking into account both inserts, upserts, and deletes):
SELECT Account__c.Id FROM Client__c WHERE Id =: Trigger.new OR Id =: Trigger.old
Then create a Set of all the Account Ids (in this example, named accounts), and run a query to retrieve ALL Clients related to those Ids (in a single query to ensure you don't hit SOQL limits).
SELECT Account__c.Id, Status__c FROM Client__c WHERE Account__c.Id =: accounts
From the results of this, you will iterate over all of the entries, tossing them into a Map keyed by the Account Id where the value is a List of Clients. When you are done, run a query to get all accounts based on the "accounts" list from earlier (which was just a list of strings, not actual Accounts), subsequently iterate over all the Clients associated with that Account, and if a Client is marked as Closed, you will update the metadata of that Account accordingly. If no Clients are closed, the Account will be marked as such. Once you are finished, run an update statement to update the list of Accounts that you have modified.