I'm developing a Web client that uses XMLA over HTTP calls to communicate with a SSAS 2016 Cube.
When my client's user clicks on a cell in a pivot grid that is based on this cube, I would like to show him a list of available SSAS "Actions" to perform.
To do so, my code uses a XMLA "DISCOVER" command with "MDSCHEMA_ACTIONS" Request Type, while restricting on the specific cell path.
I do manage to get results when I restrict on one measure and one dimension attribute member (Scenario A) - I get a rowset with one action ("the Action")
But, if I add another dimension attribute member (Scenario B), I get en empty rowset.
Naturally, I thought that this is due to the way the DBA has configured the Actions for the cells, but to my surprise, when I used MS Excel Pivot Table and queried the actions for the exact same cell (Scenario B), I did got the same Action (as wished).
I would like to use your experience to find some clues as to what might cause the different results between the two clients, given that the only apparent difference is adding the second dimension attribute.
Here are the Coordinates for both scenarios:
Scenario A (returned an action):
(
[BusinessDate].[CURRENTWEEK].&[1],
[Measures].[Total Payment Amount]
)
Scenario B (Failed to return an Action):
(
[BusinessDate].[CURRENTWEEK].&[1],
[Owners].[Owner Id].&[34876],
[Measures].[Total Payment Amount]
)
And here is the XMLA wrapper for BOTH Scenarios:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<Discover xmlns="urn:schemas-microsoft-com:xml-analysis" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<RequestType>MDSCHEMA_ACTIONS</RequestType>
<Restrictions>
<RestrictionList>
<CATALOG_NAME>my_catalog</CATALOG_NAME>
<CUBE_NAME>my_cube_name</CUBE_NAME>
<COORDINATE_TYPE>6</COORDINATE_TYPE>
<COORDINATE>COORDINATE-GOES-HERE</COORDINATE>
</RestrictionList>
</Restrictions>
<Properties>
<PropertyList>
<Format>Tabular</Format>
</PropertyList>
</Properties>
</Discover>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Appreciate any help!
PS I've tried to sniff with wireshark how exactly the Excel request looks like, but it looks like encoded ASCII that I couldnt understand.
PS2: posted also in dba.stackexchange:
https://dba.stackexchange.com/questions/183515
Related
Background: Our SharePoint Task list threshold limit reached, means items are more than 5000. We have created custom view to manage the data view with help of indexed columns.
But there is logic in SharePoint 2013 designer workflow in which we need to get description column and few other columns of task which gets completed to save it as history purposes (which user took what action and when).
Now to get information we use GUID return by Assign a task action of designer and query the completed task.
Problem: Our SP designer workflow call for task list and filter items based on GUID. Below is the sample screenshot of call from designer.
SharePoint Call to our list
and once reaching this step it throws an error in workflow, and workflow got suspended, when I drill down the reason it was due to threshold limit, I tested it on browser as shown below
Error that throw by above call in worklfow
My Approach:
To cater above problem i only have 2 points in mind:
1) To call above by Item ID instead of GUID becuase Item ID will be indexed by defauly, but Assign a task action of SharePoint designer workfow return TaskID that contains GUID so that is the reason to filter items based on GUID, but GUID is not indexed columns, so it throw Microsoft.SharePoint.SPQueryThrottledException.
2) Need to make GUID as indexed column so that threshold error can be cater. but in list settings GUID cannot be set as indexed column as its not listed there.
Question:
Is there any solution or any other way so that we can get information related to task in designer once the task completed.
We had exactly the same problem in a SharePoint Online environment. SharePoint Designer WF generates a REST call like this to get a task from the WF's associated task list:
https://site/web/_api/web/lists(guid'1b7a4526-47da-4040-8df1-ba8a97543188')/Items?%24filter=**GUID**+**eq**+guid%2771c23273-2535-4dbb-869d-c3e608899ca0%27&%24select=ID%2CEditorId
I put an index on the 'GUID' column through powershell:
Add-PSSnapin Microsoft.sharepoint.powershell
$web = get-spweb '<URL>'
$list = $web.Lists['Workflow Tasks']
$field = $list.Fields['GUID']
$field.Indexed = $true
$field.Update()
$list.FieldIndexes.Add($field)
(You have to ensure that there are no more than 5000 items in the list before you can create the index)
We did it one week ago and all the suspended workflows are resumed successfully. Now there are ~5100 items in the task list and no problem with the GUID filter.
I have two classes. One Attribut of class1 is connected to another attribut of class2. This was done with the help of the context menue of the connector in the proximity of one class, it is called Link to element feature. The same is done on the other side of the connector to select the other attribut of the other class. So the connector directly connects two attributes and not the classes itselves. I haven´t found the tables, where this infomation is stored, so I dont find the appropiate SQL to find connected (or not connected) attributes.
Here's the way for notes using Link to..
PDATA1 = 'Attribute'
PDATA2 = t_attribute.ID of the attribute
PDATA3 = name of the attribute
PDATA4 has 'Yes' (I don't recall what that's used for so you can probably ignore it
First SQL:
SELECT PDATA2 FROM t_object WHERE Object_Type='Note' AND PDATA1 = 'Attribute'
will give you the ID. Just put that in another SQL:
SELECT * FROM t_attribute WHERE ID = (above SQL)
and you have the attribute details. Or if you want to find the unmapped one just build a dissection with the found IDs from the first with the existing attribute IDs.
For associations using Link to... it's a bit more tricky. First off, any such connectors have the relevant information stored in t_connector.StyleEx like e.g.
LFEP={69A30E17-23AB-4641-9573-9BDBAA988D52}L;
LF<dir>P=<guid><pos>; connector is attached to attribute/operation
<dir> = S or E meaning Start (source) or End (target) <guid> = ea_guid of t_attribute or t_operation
<pos> is the edge (L or R) where the connector had been attached to in the moment when the link has been created. This is a superfluous information since the renderer will attach the link to whatever place is relevant.
There can be one LFSP, one LFEP or both be present in one StyleEx property
(from my Inside book)
Now you can filter that information with a SQL or (what I prefer) with a little script, since doing complex SQL string operations are not my expertise.
I have recently been tasked with a small project of setting up a periodic (somewhere between daily & weekly) data dump from an internal database to a 3rd party product. This project dovetails nicely with my company's desire (one which I share) to start standing up a formal service layer/API over the top of our data.
My personal preference is that those APIs should take on the form of RESTful endpoints - however, now I have what I think is a big design question - let me explain...
Looking at the data pull in question, it's hardly complicated. If I were just going to construct a one-off query, it would conceptually look a little something like:
select o.order_num, o.order_date, p.product_description, sr.sales_rep_name
from order o, line_item li, product p, sales_rep sr
where li.order_num = o.order_num
and li.product_id = p.product_id
and sr.sales_rep_id = o.sales_rep_id
and o.order_date >= [some arbitrary date]
Flipping my brain into "Resource Mode", I can think about how to convert this basic data model into URI's/payloads without too much trouble:
GET /orders/123
{
"order_num": 59324,
"order_date": "2014-07-07",
"sales_rep_uri": "/salesRep/34",
"line_items_uri": "/order/123/lineItems"
}
Getting more information about the sales rep:
GET /salesRep/34
{
"sales_rep_name": "Jane Doe",
"open_orders_uri": "/salesRep/34/orders"
}
Getting more information about line items:
GET /orders/123/lineItems
{
"line_items": [
{"order_uri": "/order/123", "product_uri": "/products/68"},
{"order_uri": "/order/123", "product_uri": "/products/99"}
]
}
And so on. I'm not saying it's a perfect API, I'm just trying to demonstrate it's not exactly rocket science to go about thinking how you might express the data model in a nicely normalized, resource-oriented type of way via RESTful URIs. But that is exactly where the design question comes into play...
On one hand, I can crank out a query to solve the problem very easily, but the very nature of queries requires the various domain concepts to be tightly coupled (in other words, utilizing joins to bring all of the normalized data together into one nice, custom-purpose de-normalized structure).
On the other hand, going through the mental process of thinking out a RESTful API leads me right back down that road of keeping things nicely compartmentalized - e.g. asking for "Order 123" shouldn't send me back this huge graph where I can see the full product description, the sales rep's phone number, etc, etc. The concept of a full blown HATEOAS-level RESTful API dictates consumers should be making subsequent GETs to drill down for that kind of detail only as-needed.
My question boils down to this: solving this use case seems really easy to do with a direct query and really difficult to do against a nice & tidy RESTful API (I'm picturing the literally 1000's of individual GETs it would take for me to assemble a weeks worth of data vs the few seconds it would take for the query to run). Is there some elegant subtlety of good RESTful design that I don't understand that would prevent me from seeing a good solution, or am I trying to fit a round peg into a square hole (i.e. REST is not good at pulling big data batches across multiple resources)?
I'm just going to throw this out there as a potential solution:
Conceptually, I treat the results of this query as a resource unto itself - like "orderReport".
Treating this as it's own resource, the API could behave something like:
GET /orderReport/[some arbitrary date]
You could then send back either a 201 Created (if the query is relatively quick running) with a location header like Location: /orderReport/[GUID]. Alternatively, if the query takes a while to run (I honestly don't know if it does or not off the top of my head), you could send back a 202 Accepted with a location header of Location: /orderReport/[GUID]/status.
You could then do follow up GETs against those URLs to get either the report status (200 OK if still processing without error, 201 Created with location header pointing to the report URL if its done) or the report itself.
There's nothing to say the report data couldn't also incorporate HATEOAS in addition to the data strictly needed to fulfill the use case requirements, like:
{
[
{
"order_num": 123,
"order_uri": "/orders/123",
"order_date": 2014-07-03,
"product_description": "widget",
"sales_rep_name": "Jane Doe",
"sales_rep_uri": "/salesRep/34"
},
{
"order_num": 456,
"order_uri": "/orders/456",
"order_date": 2014-07-04,
"product_description": "gadget",
"sales_rep_name": "Frank Smith",
"sales_rep_uri": "/salesRep/53"
}
]
}
I have a requirement to implement a method like this in Apache CXF JAX-RS(in a concurrent scenario)
#PUT
#Path("/customers/123")
public void updateConcurrentCustomer(Customer existingCustomer,Customer updatedCustomer,boolean forceUpdate){
......
}
In request body, i need to call this method something like this (no root element).
<Customer>
.....existing data....
</Customer>
<Customer>
......updated data....
</Customer>
<boolean>true</boolean>
How this data binding can be achieved?
I tried creating a composite wrapper Resource class like this
#XmlRootElement
public class CustomCustomer implements java.io.Serializable
{
private Customer existingCustomer;
private Customer updatedCustomer;
private boolean forceUpdate;
.....
.....
}
It works well. But i dont want to create this wrapper class.
My concurrency scenario:
customer123 object is in state A.
user1 changes customer123 to state B.
user2 changes customer123 to state C.
user3 changes customer123 to state D. (all at same time)
only high priority user sets forceUpdate flag and finally that update will be overwritten than others.
existingCustomer - will be used to detect conflict changes. It will be in state A
According to the definition
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified
version of the one residing on the origin server.
So first of all your customer needs a unique identifier like /customers/{id}. Otherwise the server can't know where the resource should be stored.
Then you don't need to pass the existingCustomer. Either there is none (new resource) or the server already knows him (because you addressed him with a unique URL).
The forceUpdate is also not senseful here. A PUT should modify if the resource already exists so forceUpdate is true be definition.
Sometimes you can't use the clear semantics of a PUT. For instance if the client does not know the id and you don't want that the client chooses one (he can't guarantee uniqueness). Then you can use a POST and the server will return the Location where he stored the Resource.
Also if you want to update only in special cases maybe depending on some other parameters a POST is the appropriate Method.
I have an issue where serializing an ORM relationship is only showing the first two records. The rest just show [] blank.
Here is an example relationship:
property name="endorsements" singularname="endorsement" fieldtype="one-to-many" lazy="false" fkcolumn="xxx" cfc="endorsements" remotingfetch="true";
Getting the JSON:
policy = entityLoad("policy",1018379202)[1];
serializeJSON( policy );
And a cut down part of the JSON:
{"id":12321,"endorsements":[{"effectiveDate":"July, 01 2009 00:00:00","active":true},
{"effectiveDate":"July, 01 2009 00:00:00","active":true},
"","","","","","","","",""]}
The empty strings should be other records in the relationship.
I've verified via debug files that the Hibernate query is bringing back all records and a cfdump shows this as well.
Thoughts?
The bug occurs in coldfusion.runtime.JSONUtils.serializeJSON() at around line 409.
If you are serialising a persistent cfc, it adds the fully qualified name of the cfc to an ArrayList, which is passed around recursively.
Then there is an if() statement which tries to locate the cfc's fully qualified name and once it appears more than twice in the list, leaves the function early with "{}".
Not really sure what they were trying to accomplish with this if().
Possibly to handle circular references?
This bug was logged back in April: https://bugbase.adobe.com/index.cfm?event=bug&id=3175667