I've read the documentation, and I get the REST API GET URL...
http://localhost:8080/ssc/api/v1/projectVersions/6/resultProcessingRules
To work and return a list of the 'Profile - Processing Rules' for my application (via ID 6).
e.g.
"data": [
{
"displayName": "Require approval if the Build Project is different between scans",
"identifier": "com.fortify.manager.BLL.processingrules.BuildProjectProcessingRule",
"enabled": true,
"displayable": true
}
What I can't get to work is the PUT command to set this from 'enabled=true' to 'enabled=false'
I get back the same error message each time...
{
"message": "An unexpected error occurred accessing resource of type Project Version Result Processing Rules.",
"responseCode": 500,
"errorCode": -20010
}
And the log just says...
2016-11-27 23:24:40,076 [ERROR] com.fortify.server.platform.endpoints.rest.ProjectVersionResultProcessingRulesController - ApiGeneralResourceException: 'An unexpected error occurred accessing resource of type Project Version Result Processing Rules.' [url: /ssc/api/v1/projectVersions/6/resultProcessingRules]
2016-11-27 23:24:40,077 [WARN] org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver - Handler execution resulted in exception: java.lang.String cannot be cast to java.util.List
Can anyone tell me what the correct payload should be for this command?
Using Postman, I got this to work:
Here are the headers I used
Authorization = FortifyToken A13D...E2
Content-Type = application/json
Accept = application/json
And here is the body:
[
{
"displayName": "Require approval if the Build Project is different between scans",
"identifier": "com.fortify.manager.BLL.processingrules.BuildProjectProcessingRule",
"enabled": true,
"displayable": true
}
]
NOTE
The trick I have used when trying to figure out who to call the REST API is to perform the action through the HTML5 UI while looking at the traffic (Fiddler, the browser's dev tools, etc). Then looking at the requests that it sends. The HTML5 interface uses the REST API under the hood.
Related
I am trying to write a bash script to disable/enable a pipeline in Azure Devops.
I just need to perform a PUT request as per the documentation.
But first I need to run a GET in the same endpoint to get json, then modified it and send back using PUT.
The GET request works fine
Get request
https://{{coreServer}}/{{organization}}/{{project}}/_apis/build/definitions/453?api-version={{api-version}}
Response status code 200
...
"id": 453,
...
"type": "build",
"queueStatus": "disabled",
"revision": 8,
...
The PUT request URL:
https://{{coreServer}}/{{organization}}/{{project}}/_apis/build/definitions/453?api-version={{api-version}}
The PUT body
...
"id": 453,
...
"type": "build",
"queueStatus": "enabled",
"revision": 9,
...
Response from PUT:
"$id": "1",
"innerException": null,
"message": "Build pipeline 453 was not found.",
"typeName": "Microsoft.TeamFoundation.Build.WebApi.DefinitionNotFoundException, Microsoft.TeamFoundation.Build2.WebApi",
"typeKey": "DefinitionNotFoundException",
"errorCode": 0,
"eventId": 3000
}
The token to connect has the correct scope and permission.
How is possible to find the correct resource on GET but not on PUT?
What I am missing?
By checking your API, you are using Definitions-Get to get json, and using Definitions-Update to change the "queueStatus".
Tested on my side, it works well. In common, you could use the response from GET API as requested body of PUT API. You could follow my steps and have a check on your side.
I am using GET to get the target pipeline definition. Basic OAuth.
Using PUT to disable the queueStatus with the json body from above GET API
Updates an existing build definition. In order for this operation to succeed, the value of the "Revision" property of the request body must match the existing build definition's. It is recommended that you obtain the existing build definition by using GET, modify the build definition as necessary, and then submit the modified definition with PUT.
From your GET API, the revision is 8. Do not modify the revision to 9, just change the "queueStatus" and keep the same revision 8 as GET json to make sure the revision is matched.
Modify your PUT body as below:
...
"id": 453,
...
"type": "build",
"queueStatus": "enabled",
"revision": 8,
...
We use a web activity in ADF v2 to interact with the Azure Automation Account API (Job creation) based on this specification https://learn.microsoft.com/en-us/rest/api/automation/job/create
Since 09-04-2020 the PUT web call isn't working because the header "Content-Type : application/json" is not being sent. The pipeline that contain the activity hasn't changed in months, just stopped working suddenly with the error:
Operation on target Automation - AAS Processing failed:
{
"code": "UnsupportedMediaType",
"message": "{\"Message\":\"The request entity's media type 'text/plain' is not supported for this resource.\"}"
}
But the input request for the pipeline, does include the header:
{
"url": "https://management.azure.com/subscriptions/xxxxx/resourceGroups/xxxxx/providers/Microsoft.Automation/automationAccounts/xxxxx/jobs/55a1bfa2-340c-4120-ba42-43df9e9f4e14?api-version=2017-05-15-preview",
"method": "PUT",
"headers": {
"Content-type": "application/json"
},
"body": "{\"properties\":{\"runbook\":{\"name\":\"aas-masterdata-management\"},\"parameters\":{\"Masterdata_Table\":\"RLS\"},\"runOn\":\"\"}}",
"authentication": {
"type": "MSI",
"resource": "https://management.azure.com"
}
}
I've tried so far:
Recreate the pipeline
Test in a different ADF instance
Delete and redeploy all the pipelines
Delete the header
Change the header to lowercase, uppercase, etc
Add the header twice
Use a self-hosted integration runtime
Test in Debug mode
Any of these tests have been successful. Just for confirmation, I've run the same call from Postman and from the rest api debug tool included within the Api documentation, both worked perfectly, if I set the content header to text/plain in postman or in the web tool I get exactly the same error than in ADF v2. It seems that something has changed in the web call activity of ADF v2 that hardcodes the content header as "text/plain" somehow.
Is someone facing this same issue ? As I said, pipeline definition hasn't changed in months, just stopped working few days ago.
Answer from the ADF platform team:
I got update from Product team that using "Content-Type" instead of "Content-type" will resolve this issue. This can be referred in the documentation
It seems that they accepted "Content-type" before, as it was working several months with that config, but not anymore. So if someone experiences the same problem, here is the answer.
Thanks.
If you are creating the ADF webhook activity using a bicep file, I found this approach works to set the Content-Type in the header parameter.
Define a string variable with the hyphenated Content-Type name
Use string interpolation to include the variable in the headers param
var contentType = 'Content-Type'
activities: [
{
dependsOn: []
description: ''
name: 'MyWebHook'
userProperties: []
type: 'WebHook'
typeProperties: {
body: {
value: '#json(concat(\'{"data":"\',item().data,\'","startTime":"\',item().startTime,\'","endTime\\":"\',item().endTime,\'"}\'))'
type: 'Expression'
}
headers: {
'${contentType}': 'application/json'
}
method: 'POST'
reportStatusOnCallBack: true
timeout: '00:10:00'
url: listCallbackURL('${logic_app_id}/triggers/manual', '2016-10-01').value
}
}
]
Working in Blue Prism .Net environment utilising the HTTP utility to make calls to Axios Assyst (an IT service desk 3rd party software).
My HTTP request is as per below:
POST /assystREST/v2/site/10/attachments/binary HTTP/1.1
Host: <myserver>:<myport>
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary<base64 encode here>
Accept: application/json
Authorization: Basic <base64 encoded key>
{
"eventId": 10010045,
"fileName": "C:\Users\Me\Desktop\MyFile.msg",
"attachment": "data:;base64,<base64 encoded file>
"onBehalfOfUser": "MR ROBOT",
"custom": {},
"attachedByUserId": <my ID>,
"name": "C:\Users\Me\Desktop\MyFile.msg",
"event":{
"assystRESTType": "event",
"assystRESTXMLType": "eventDto",
"id": 10010045
},
"attachedByUser":{
"assystRESTType": "assystUser",
"assystRESTXMLType": "assystUserDto",
"name": "Mr Robot - Test",
"id": <my ID>,
"shortCode": "MR ROBOT"
}
}
I can create and close my tickets but unable to send/save files to my newly created tickets. I get a HTTP STATUS CODE 410-GONE and the below exception JSON response:
{
"type": "NotFoundException",
"message": "The requested resource is not available.",
"messageKey": "rest.exceptions.NotFoundException",
"diagnostic": "Could not find resource for relative : /site/10/attachments/binary of full path: http://server:port/assystREST/v2/site/10/attachments/binary"
}
I'm following the instructions and guidelines noted in the official Axios Assyst Web Service wiki(per the below link), i.e. I'm using multipart/form-data while sending the file, a .msg file, and the binary of said file (yes I know this adds 33% more to the file size): https://wiki.axiossystems.com/assyst10SP75Wiki/index.php/Integrations:assystREST#Attachments
My issue is that 400 status codes would denote an issue on the client side but I've checked internally re firewall/port being used and nothing is being blocked.
I've reasearched 410 status codes and it would seem that the issue is server side but one that the server is not willing to elaborate on.
For testing I'm using Postman as it allows for greater flexibility rather than using Blue Prism, the JSON response is the same.
Looking for some guidance re status code 410 and possible solutions, note I've limited scope re options due to Blue Prisms .net vbo's.
Please provide the solution for this (I am new to jersey and postman). I tried with below link but unable to share the file: https://www.hipchat.com/docs/apiv2/method/share_file_with_room
I attached screen shots, which I tried from postman.
Note: I used API access token with send message scope.
I am getting below error as response:
{
"error": {
"code": 400,
"message": "No file was found in the request. See https://www.hipchat.com/docs/apiv2/method/share_file_with_room for an example",
"type": "Bad Request"
}
}
I am Very new to Kurento. I went through its json-rpc documentation from this link.
http://www.kurento.org/docs/5.0.3/mastering/kurento_protocol.html
1) I have installed a local kurento server which runs on the port 8888.
2) I used a tool called wscat to establish a connection to the kurento-websocket.
3) I tried to connect to the kurento-server with below command
wscat -c ws://localhost:8888/kurento
After that i got the connected prompt from the server.
From the above kurento protocol documentation link. I have used the below request json
{
"jsonrpc": "2.0",
"id": 1,
"method": "create",
"params": {
"type": "PlayerEndPoint",
"creationParams": {
"pipeline": "6829986",
"uri": "http://host/app/video.mp4"
},
"sessionId": "c93e5bf0-4fd0-4888-9411-765ff5d89b93"
}
}
But according to the docs the response which i should get after sending this request is like this.
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"value": "442352747",
"sessionId": "c93e5bf0-4fd0-4888-9411-765ff5d89b93"
}
}
But i am getting
{
"error":
{"code":-32603,
"message":"Unexpected error while processing method: Factory PlayerEndPoint not found"
},
"id":1,
"jsonrpc":"2.0"
}
If i am not wrong the above request-json is used to create a new media pipeline for player end point which is used to stream http://host/app/video.mp4.
Is there any problem in my request-json object or do i have to do something before giving this request.
please help me.
You have several problems. The first is that PlayerEndpoint is not correctly spelled (note the lower case "p" PlayerEnd-p-oint). The second is that you need to first to create a MediaPipeline before you can create a PlayerEndpoint or any other media element.
If you are new to Kurento, my recommendation is that you should try to use the official Kurento client implementations (currently available in Java and JavaScript). If you want to create your very own Kurento client, you'll need to read carefully the documentation because there are a lot of details you'll need to manage (e.g. the distributed garbage collector, the WebSocket reconnection mechanisms, etc.)