Receive Prompts from a report using REST services for Pentaho - rest

I was wondering if it is possible to receive the prompts used (with possibly all it's options) in a report using REST services.
What I like to achieve is receiving the prompts and if possible all the options for those prompts in an XML format from any given Pentaho report. I know there are rest calls for basic repository listings etc... but I can't seem to find this specific call.

It is possible to get full parameters xml (which includes parameters, parameters values, parameters attributes as far as info which is used to create report prompts) - full parameter info. You need bi server and reporting plugin. The url is:
http://localhost:8080/pentaho/api/repos/"%"3Apublic"%"3ASteel"%"20Wheels"%"3AInventory"%"20List"%"20(report).prpt/parameter
And we have to pass parameter renderMode with value: PARAMETER.
Here we call to report under /public/Steel Wheels/Inventory List (reprot).prpt
or simplifying -
"http://localhost:8080/pentaho/api/repos/<path_to_report>.prpt/parameter"
You can open browser and inspect requests responses just on fly:
On a screen is actually parameter requests you are looking for.

Related

how to upload file in Advanced Rest Client

I am trying to use post method in this add Attachment to SAP ODATA service (URL), then I am getting the error
"Key 'file_name' not given".
I used Multippart/form-data and given file_name (with single cotes and with out it) still the error is same.
Any idea where to give file_name?
Thanks.

Apache ManifoldCF: Get a history report for a repository connection over REST API

I'm trying to get a history report for a repository connection over ManifoldCF REST API. According to the documentation:
https://manifoldcf.apache.org/release/release-2.11/en_US/programmatic-operation.html#History+query+parameters
It should be possible with the following URL (connection name: myConnection):
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection
I have also tried to use some of the history query parameters:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?report=simple
But I am not sure if I am using them correctly or how they should be attached to the URL, because it is not mentioned in the documentation.
The problem is also that I don't receive any error, but an empty object, so it is difficult to debug. The API returns an empty object even for a non-existing connection.
However it works for resources, which doesn't have any attributes, e.g.:
http://localhost:8345/mcf-api-service/json/repositoryconnectionjobs/myConnection
or
http://localhost:8345/mcf-api-service/json/repositoryconnections/myConnection
Thanks in advace for any help.
I also wrote a message to ManifoldCF team and they gave me an answer. So I summed up it for you below.
Query parameters go after the fixed "path" part of the URL and are of the form ?parameter=value&parameter2=value2...
So in the same way as in any other URL.
The problem was that I didn't supply the activity(s) that I wanted to match. Possible activities are e.g. fetch, process. My example:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?activity=process&activity=fetch
Finally, the reason why I didn't get an error when I used a connection name that is bogus is because the underlying implementation is merely doing a dumb query and not checking for the legality/existence of the connection name.

Outlook rest api "synchronize messages" ignores $expand in subsequent calls

I am trying to synchronize an Outlook folder (say the Inbox) using the beta version of the Outlook Rest Api see doc here
I need only to retrieve the property IsRead and the PR_INTERNET_MESSAGE_ID
So following documentation, for the first synchronization my requests look like:
The following Http headers are always added:
request.Headers.Add("Prefer", "odata.track-changes");
request.Headers.Add("Prefer", "odata.maxpagesize=5"); //Use a small page size easier for debugging
The first initial full synchronization request
https://outlook.office365.com/api/beta/Me/MailFolders('inbox')/messages?$select=IsRead&$expand=SingleValueExtendedProperties($filter=(PropertyId eq 'String 0x1035'))
Good results the value array contain what I need.
The second request after the first request uses the deltatoken
https://outlook.office365.com/api/beta/Me/MailFolders('inbox')/messages?$select=IsRead,Subject&$expand=SingleValueExtendedProperties($filter=(PropertyId eq 'String 0x1035'))&$deltatoken=a758b90491954a61ad463ef3a0e690a2
Bad results, no SingleValueExtendedProperties entries
Next requests for paginations with skiptoken...
https://outlook.office365.com/api/beta/Me/MailFolders('inbox')/messages?$select=IsRead,Subject&$expand=SingleValueExtendedProperties($filter=(PropertyId eq 'String 0x1035'))&$skiptoken=e99ad10324464488b6b219ca5ed6be1c
Bad results again, same as 2.
It looks like a bug to me. Can you provide a workaround? From a list of ItemId is possible to retrieve easily the list of corresponding PR_InternetMessage_Id efficiently (not item per item)?
Note also that in the documentation it is written that:
The response will include a Preference-Applied: odata.track-changes
header. If you attempt to sync a resource that is not supported, this
header will not be returned in the response. Check for this header
before processing the response to avoid errors.
It seems that for 2. and 3. calls this response header "Preference-Applied" is not set.
The sync functionality today doesn't support extended properties. However, we are working to enable this and it should start working in a few weeks.
EDIT:
For a workaround for the very special case of the PR_INTERNETMESSAGE_ID look at the comment below.

Pass rest resource output format in url

AFAIK every resource have a url in REST design. for example /user/28 is url of user with id equal to 28 and /users will return all users.
There are some way to represent output format of the resource:
passing a query parameter like format
specify it using extensions(changing /users url to /users.json to get the users in json format)
specifying the requested format(xml, json, xls, ...) by setting Accept http header.
I search the web and it seems the correct way is setting Accept header.
But if you want to have a http link (specified by href) to download list of users in xls format, you can't!Also if you want to download the xls by the browser, you will encounter many problems(you should use ajax so the xls should download using ajax and etc.)
If it is the best way, what is the solution for download link and if its not, which solution is better?
The Accept header is considered 'more correct', but there are plenty examples of all the options you mention. As far as I can tell, none of them is considered "bad". Personally, I'd say that you should honor and prefer the Accept header, but a format query parameter should override it, if present. The downside of the 'extension' method is that each format results in a different resource, which can get ugly.

Sending and retrieving a constant field

I'm using Filemaker 11 to manage content over Custom Web publishing, with a json xslt sheet to convert the XML to a json format is there any way to add a parameter to the url, and have it come back down without modifying it?
I thought about globals, but from what I can tell if two requests were sent within a short enough amount of time, there could be a race condition, one overwriting the others global..
Parameters are passed to the stylesheet in <xsl:param name="request-query" />, whose structure must be specified in the documentation, but as far as I remember it's
<query action="..."> <-- the form action, i.e. the url -->
<parameter name="...">...</parameter>
</query>
The query namespace is http://www.filemaker.com/xml/query. FileMaker's own idea of passing custom parameters is to name them like token.1, etc., but it's possible to pass just any set of parameters to a XSLT that uses a process action (i.e. doesn't hit the database), sort the parameters out into what goes into the db and what stays, make an inline call, and then process the result and add the saved parameters back.
Note that you also can access the cookies and the headers, if you need. Also note that XSLT API is deprecated and won't be supported in future FileMaker version.