I'm using Snaplogic to load records into workday. Trying to load invoices into workday using the object Submit_Customer_Invoice of web service Revenue_Management. I'm getting the following error:
"error": "Processing error occurred. The task submitted is not authorized."
The documentation for workday is not helpful.
Does this error occur if I mess up the SOAP call or is it an access issue?
Any help will be appreciated.
It is an access issue. The user you are making requests with does not have the correct permissions.
When I was working with an implementation team and we switched to a different tenant that error started popping up. The Workday implementer went into that tenant, tweaked some security settings (Sorry, not on the workday side so don't know where or what) and the service calls started working again.
For anyone else getting errors, you can run the task Security Analysis for Action in the tenant, select the webservice request in the Action dropdown, and then select an account that has access to that service (like an impl account, you don't need to have access to the account) and click Show Details. This will give you a list of all the security Domains you need to add to the account to process the request.
Related
I am trying to use the NetSuite SuiteTalk REST Web Services to access NetSuite CRM data.
I have the access up and working in production. Able to retrieve record data and metadata.
I am now trying to set up access in the sandbox for more in-depth testing.
In the sandbox I have:
- Enabled rest web services
- Enabled token based authentication
- Given user concurrent web services permission
- Given user Log in using access tokens permission
- Created an integration
- Created an access token
All of these actions mirrored what was done in production.
When I attempt any kind of GET to the web service, I receive a 401 - Invalid login attempt.
When I check the Login Audit Trail, I don't see any record of the GET attempt, failed or otherwise.
Is there something of a systemic nature that I have to do additionally in the sandbox to enable rest web services? Above and beyond enabling it in SuiteCloud/SuiteTalk?
The fact that I see absolutely nothing in the audit trail makes me believe that something is still "turned off".
===> 4/4/2020 Update
ed14 and Nihkil,
Thank you for your responses, and sorry for the delay in responding back.
The hyphen to underscore in the realm did not help me unfortunately.
Let me recap recent attempts:
1) Started by verifying that REST API testing in production still works.
2) The sandbox was refreshed by a CRM admin. The application was still there, but my access token was not. I created a new one in the sandbox.
Is it possible to delete the application? I cannot see any way to do that.
3) Tested with existing Consumer Token and new Access Token. Got the same response as from my first post: "title": "Invalid login attempt, for more details see Login Audit Trail.",
4) Tested by slightly modifying the URL to make sure I was not going to a black hole somewhere. It gave me the expected error.
5) Tested by modifying the realm: Realm 9999999-sb4 to Realm 9999999_sb4 It gave me an error which leads me to believe that my original realm is correct: "title": "An unexpected error occurred. Error ID: k8hd8pqej3unxblmaoik",
Again, none of the tests show up in anywhere in the audit log as a failed attempt.
Not sure where to go from here? Delete the sandbox application (if possible) and start again? Or new application in sandbox?
Thanks for any and all help.
Bryan Hunt
I had the same issue using the sandbox. Apparently there is a mismatch between the account ID (used in realm authorization) and the account ID in the URL.
The account ID (realm): XXXXX_SB1
The account ID in the url: XXXXX-SB1
The SB should be in upper case.
This solved the problem for me.
As #ed14n and #nikhil-abraham said, changing - to _ in authorization realm and put the SB in UPPER CASE solve this problem here.
If you are using POSTMAN template provided from NetSuite, your envs should be like the image below.
In Postman in your request tab and then in the authorization tab in the advanced section there is a field called Realm. Put the account id in the realm field with underscores.
First, I'm using Spring, Jetty, Retrofit.
When I use calendarView in local, they return the successful values successfully.
But, When others connect to my local server and call this api, it always returns me 403-AccessDenied error.
(additionally, When they call another ms api, they return the successful values.)
I think I have set all the recommended permissions in Graph api.
But this could be my illusion.
In order for someone else to call api from my local server, what should I do?
Or Am I missing anything on this matter?
These are my permissions.
"openid",
"offline_access",
"profile",
"User.ReadWrite",
"Mail.ReadWrite",
"Calendars.ReadWrite",
"User.ReadBasic.All",
"BookingsAppointment.ReadWrite.All"
This is my azure info.
And I'm using this calendar view api
https://learn.microsoft.com/en-us/graph/api/calendar-list-calendarview?view=graph-rest-1.0&tabs=http
And Using This URL in my code(in this case, I'm using batch request)
GET | "/users/"+getAddress()+"/calendarView?startDateTime="+getStartTime()+"&endDateTime="+getEndTime()
Based on your description, other users are trying to access the calendarView of the user "{Room}".
In this case, you need 2 more configurations.
User "{Room}" gives mailbox permissions "Full Access" to other users
in Office 365. See Use the EAC to assign permissions to individual
mailboxes. (you should be able to find the room under
Resources. And the process can take up to hours for the changes to propagate through the system and be in effect.)
Add one more delegated permission: Calendars.ReadWrite.Shared into
the app registed in Azure AD.
I am trying to use the Google APIs Console to create an OAuth 2.0 Client ID as a Service Account. This ID will be used to query my Google Analytics data through the Analytics API. However, when I attempt to create the Client ID, the APIs Console displays the message, "An error has occurred. Please retry later." I have tried several times throughout the last two weeks, but I keep getting the same error message. Can anyone advise me on what I'm doing wrong? Or is there another way that I can access my Analytics data via the API without an OAuth Client ID?
I figured out the issue. Apparently, the Google APIs Console does not allow a collaborator account to create new OAuth Service Accounts, only the owner account can do so.
In the .NetAggCatSample app, I've found that calling getInstitutions with an existing user context seems to work fine, but for new users, I'm getting an exceptions (message = "forbidden").
Could this be due to running into the max user limit in Dev mode (which I am in)?
Also, which API call actually creates the user at Intuit?
To add the answer,
Any API call after retrieving OAuth tokens from the SAML assertion will create the user in the system. As you mentioned, you are most likely getting the 403 error because you are at your max customer limit. Please enable logging and post the response XML from the call that returns a 403:
http://docs.developer.intuit.com/0020_Aggregation_Categorization_Apps/DevKits/0250.NET_AggCat_DevKit_1.0/0006_Logging#Request_and_Response_Log
thanks
Jarred
My application, created today, runs fine when I use it with my account. On any other account however, the following error is sent back as a response:
message: "(#298) You must be a developer of the application"
type: "OAuthException"
The exact code I'm using to send the request is this:
FB.api('/me/threads', {limit: 1000}, function(response){ ....
I have found someone experiencing the same problem, but the response he accepted didn't really provide any useful information. ( Reading over inbox, I get error #298).
Anyone have a clue on how to solve this? Would be greatly appreciated!
I'm guessing you have the read_mailbox permission?
Try accessing the /me/inbox connection instead?
Facebook tells you (from http://developers.facebook.com/docs/reference/api/thread/):
Please note: We are in the process of making the new messages system
available to all users, at which point this API will replace the
/inbox/ Graph API endpoint. We are providing early access to this API
for registered developer accounts only until the new messaging system
is broadly available. You should use the /inbox endpoint for
production applications at the current time.
That is, only the current apps developers will be able to use the threads-connection for now (but it will be available later).
It looks like your other account doesn't have a developer license/flag/attribute, thus failing the authentication check.