I have created a destination for VDM called ErpQueryEndpoint and have unsuccessfully attempted to obtain business partner info with one of the java VDM tutorials. Below is an export of that destination - I've tried this with and without TrustAll = true. When I use the 'Check Connection' button on the Destination screen, I get "302: Redirect" instead of 200. When I attempt to navigate to the URL below from Chrome, it re-directs me to a non-SAP logon screen. (I believe our Basis team has tried to set-up SSO with Azure.) I'm wondering if this redirection is what is causing my java VDM program to fail.
#Password=<< Existing password/certificate removed on export >>
#
#Mon Mar 11 15:17:38 UTC 2019
Description=ErpQueryEndPoint for java programs that use Virtual Data Model (VDM)
Type=HTTP
Authentication=BasicAuthentication
Name=ErpQueryEndpoint
ProxyType=Internet
URL=https\://my######-api.s4hana.ondemand.com
User=S000#######
Thanks for your help. The tutorial program is now working. Getting a 302: Redirect when clicking 'Check Connection' was not the problem. Even though only the base URL was in the destination, I still needed to supply the credentials from the business partner communication arrangement. (It is also works for sales contracts when I supply the credentials from its respective communication arrangement.)
Related
I have a webapp in production that interacts with Google Drive through Google Drive API.
I need to change some settings in Drive interaction but I can't save.
When I save the Drive UI integration page, I receive this error:
There's a problem at our end.
Please try again. If the problem persists, please let us know using
the "Send feedback" link below. Thanks!
(spying Network console: there is an Internal Server Error in a POST call)
I tried to send feedback for months: nobody answers and the bug is still there.
I tried also to create another project: I can save the first time but then the bug returns.
How can I do? Has someone the same problem?
Is there a way to receive a reply from Google? Is there some workaround?
Thank you.
i think that problem must be Client ID
before adding Client ID, go to the Credentials -> OAuth 2.0 Client IDs
then select edit your Client ID. after that your production site url add to Authorized JavaScript origins and Authorized redirect URIs.
then enter your Client ID in Drive UI integration page
For myself trying to get the Drive UI configured I noticed a couple of errors (that don't have any specific error messages)
When adding in an Open URL it has to be a valid domain, so for instance I tried to test it out with local host, to no avail. However something like https://devbox.app.com worked, but something like https://localhost:8888 does not. Even though https://localhost is a valid javascript origin in the client_id configuration (at least for the app I am working on, not sure about other apps), localhost doesn't work as an open URL.
When adding in the mimeTypes it needs to be in the format */* and can include custom mimeTypes like application/custom+xml and application/custom-name+json not sure for other custom types that are not in a particular format like xml or json. Also not sure about wildcards.
When adding in file extensions do not add in the '.' just the name of the file extension.
The app icon I found only failed to upload the image when the image wasn't the exact dimensions, I actually ended up editing some icons in photoshop to change the pixel x pixel values as a quick work around during dev.
That worked for me to get it to save and I tested it with a file that had a custom mimeType (application/custom-name+xml specifically) and custom file extension!
I've got a working basic Java App that uploads some data to a google sheets file of mine.
I uploaded it to a git client, pulled it to my other computer, and it doesn't work on that with a 401
Exception in thread "main" com.google.api.client.auth.oauth2.TokenResponseException: 401 Unauthorized
at com.google.api.client.auth.oauth2.TokenResponseException.from(TokenResponseException.java:105)
at com.google.api.client.auth.oauth2.TokenRequest.executeUnparsed(TokenRequest.java:287)
at com.google.api.client.auth.oauth2.TokenRequest.execute(TokenRequest.java:307)
at com.google.api.client.auth.oauth2.Credential.executeRefreshToken(Credential.java:570)
at com.google.api.client.auth.oauth2.Credential.refreshToken(Credential.java:489)
at com.google.api.client.auth.oauth2.Credential.intercept(Credential.java:217)
at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:868)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:419)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.executeUnparsed(AbstractGoogleClientRequest.java:352)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.execute(AbstractGoogleClientRequest.java:469)
at App.main(App.java:71)
Any idea what could be different between the two machines? I understand it that if I'm using the same client_secret.json, it should be irrelevant which machine I'm on?
UDPATE 1:
ok, some extra info - i just tried my project at work on my work laptop and it worked fine! On first run it opened a browser window and asked me which google account I wanted to use, I chose the correct one, and that worked. On the laptop I have that didn't work, I wasn't given that option (that I remember) so how can I reset the google account that has been used to authenticate against?
I saw this in my cmd line
Please open the following address in your browser:
https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=blah-notputtingmyrealid.apps.googleusercontent.com&redirect_uri=http://localhost:42299/Callback&response_type=code&scope=https://www.googleapis.com/auth/spreadsheets
Attempting to open that address in the default browser now...
Since it's working on your previous computer, the issue might be concerning the location of your client_secret.json. If you check the Java Quickstart setup, there's a part where you need to download the JSON file and place it on your working directory. Since, you're on a new machine, that file is now missing.
g. Click the file_download (Download JSON) button to the right of the
client ID.
h. Move this file to your working directory and rename it
client_secret.json.
Or the access token has expired.
I have an issue with FileNet-p8:
All simply, I do not have access to a WorkFlow already designed. I have always a popup asking me to authenticate , I use the same Login/psw to access to the Workplace. But always I get the same message :
Unable to get the configuration file WcmApiConfig.properties
I'm workin with the IBM JVM 1.6 and the Firefox browser.
Thanks.
In our environment, you must use IE in order to avoid that error message. We have not been able to get FireFox to work with WorkplaceXT or PCC.
Even when launching PCC from ACCPE we need to use IE.
If you see the login screen, don't even bother with your credentials. It simply will not work.
I'm trying to set up an MVC application that will service several facebook applications for various clients. With help from Prabir's blog post I was able to set this up with v5.2.1 and it is working well, with one exception.
At first, I had only set up two "clients", one called DemoStore and the first client, ClientA. The application determines what client content and facebook settings to use based on the url. example canvasUrl: http://my_domain.com/client_name/
This works for ClientA, but for some reason when I try any DemoStore routes I get a 500 error. The error page points to an issue with the web.config.
Config Error:
Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'facebookredirect.axd'
I am able to add additional clients with no problem, and changing DemoStore to something like "demo" while using the same facebook application settings works fine also.
Working calls:
http:// localhost:2888/ClientA/
http:// localhost:2888/ClientB/
http:// localhost:2888/Demo/
Failing call:
http:// localhost:2888/DemoStore/
I was thinking this might be an MVC issue, but the Config Error points to the facebookredirect handler. Why would the SDK try to add this value to the config during runtime, and only for this specific client?
Any insight would be greatly appreciated.
I managed to figure out what went wrong here. Silly mistake..
After I had set up the application routes to require the client_name I changed the Project Url in the project properties to point to demostore by default. When I hit ctrl+S a dialog popped up that I promptly entered through without reading.
When I changed the Project Url, IIS Express created a new virtual directory for the project. This was the source of my problem. Why? I'm not sure, but once I removed the second site from my applicationhost.config I was able to access the DemoStore routes.
Moral of the story: read the VS dialog messages!
Recently the search crawler stopped working on my MOSS installation. The message in the crawl log is
Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)
The default content account is an admin on the site collection that I am trying to crawl.
Almost every result for this error on Google tells me to add the DisableLoobackCheck registry key with a value of 1. I have done this and rebooted and the error continues.
The "Do not allow Basic Authentication" checkbox in my crawl rule screen is unchecked.
Is there anything else that could be causing this error? Something with file system or database permissions maybe?
Edit: All signs seem to indicate that the "DisableLoopbackCheck" should fix this, but it doesn't seem to work. Could I be doing something wrong when I enable this?
I'm doing it in My Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, where I create a new DWORD key called DisableLoopbackCheck and give it the hex value 1.
It turned out not to be related to DisableLoopbackCheck. The problem was that the search was accessing the site through its external URL. You are supposedly not supposed to be able to access a site from within a server using the same URL that you use to reach it from the outside, at least in pre-SP1 MOSS. But I was doing this for about two years somehow. MS Support tells me they don't quite understand how it was ever working. So it looks like I ran into an issue that should have been manifesting all along. I'm not sure what caused it to appear suddenly, maybe some routine patching of the server. The solution was to extend the web application so it was accessible internally through the machine name, then point the crawler at that.