I have a SAP server with below information (must use saprouter to connect to it from afar). (3rd picture)
And i have an Odata service that i connect on LOCAL like below. (2nd picture)
Now in SAP Web IDE, i want to connect to this Odata. (1st picture)
The picture is an example to connect to Northwind Odata test server.
I need to replace the northwind odata url with my Odata url in 2nd picture.
But this url is only for local.
So how can i config this? I think it has something to do with the saprouter.
And how can i include the username and password for the Odata too?
SAP Web IDE
Odata
SAP SERVER
These are the steps you need to follow:
You need to expose your OData service in your NW system. I think this can be done in the /iwfnd/maint_services transaction. But Google it, because I am not a system administrator.
Once done you should be able to access de OData inside your internal Network like this:
Https://host:port/sap/opu/odata...
Where host:port is the full qualified domain of your NW system.
The Cloud Platform is in the cloud (obviously), this means that it is outside your private network, so you need to configure a secure tunnel to pass your firewall. This way you can access from your SCP account to your NW in your private network.
To configure this tunnel, SAP provides a great tool called "SAP Cloud Connector". You can download it from here
Google some tutorials to configure it. There are tons and it is easy.
Now configure a destination in the Cloud Platform cockpit. As I can see in the pictures you already did it for the Nortwind service, so I guess you know how to do it. The main difference will be that instead of pointing to Nortwind, it will point to your NW system thought the Cloud Connector.
Last, change the line of the manifest.json file you highlight in the first picture, so it points to the new destination.
And that's it!!
Related
I have two apps I wanted to have "fully managed" by Cloud Run. One is a pure Vue.js SPA and the other is the belonging backend server for it that is connected to a MySQL and also fetches some other API endpoints.
Now I have deployed both apps but am totally unaware on how I can give the frontend app access to the backend app. They should be both running on the same domain to avoid the frontend from.
Current URL of the frontend app: https://myapp-xl23p3zuiq-ew.a.run.app
So I'd love to have the server accessible by: https://myapp-xl23p3zuiq-ew.a.run.app/api
Is this somewhat possible to achieve with Cloud Run?
I was having the same issue. The general idea that one usually has is to use path mapping and map / to your client and /server to your backend. After googling for a while I found this:
https://cloud.google.com/run/docs/mapping-custom-domains
Base path mapping: not supported
The term base path refers to the URL
path name that is after the domain name. For example, users is the
base path of example.com/users. Cloud Run only allows you to map a
domain to /, not to a specific base path. So any path routing has to
be handled by using a router inside the service's container or by
using Firebase Hosting.
Option1:
I ended up creating an "all in one" docker image with an nginx as reverse proxy and the client (some static files) and server (in my case a python application powered by uwsgi).
If you are looking for inspiration, you can check out the public repository here: https://gitlab.com/psono/psono-combo
Opttion2:
An alternative would be to host your client on client.example.com, your server on server.example.com and then create a third docker run instance with a reverse proxy under example.com.
All requestes would be "proxied" to the client and server. Your users will only interact with example.com so CORS won't be an issue.
Option3:
Configure CORS, so people accessing example.com can also connect to server.example.com
Currently this is not possible in Cloud Run, as already said on the comments to your question.
You could check if there are any Feature Request for this functionality on Buganizer (Google Issue Tracker), currently there seems to be none, and if that is indeed the case, you can create a new Feature Request by changing the request type from Bug to Feature Request and as Google develops it on their road map, you will be informed.
Hope this helped you.
I'm trying to configure Azure Data Lake Store Gen1 (ADLS) as a Data Source in a Data Virtualization software (Tibco's).
Reading through the Azure documentation, I got to the webhdfs/v1/ endpoint associated with ADLS and managed to simulate the (non-standard, since it requieres an additional "resource" parameter) OAuth2 authentication needed within Postman. All good so far.
I am guessing that the connection should be configured as an OData service, since the OData connector within TDV (Tibco DV) has an "Azure AD resource" parameter that should be used only if you are trying to authenticate through azure's active directory (the non-standard part from before). However I am failing to configure this connection.
This must be because of one of these reasons:
The /webhdfs/v1/ endpoint is NOT an OData service.
I am wrongly configuring the OData connector in TDV.
In any case, how can I connect to this repository and introspect everything behind it? list folders, files, and all that within TDV?
Some suggestions I have stumbled upon are using the Hive connectors or the REST connector, but after trying I still feel closer to success with OData.
I am new to SAP and development of SAP Fiori Application. I want to create a project consuming oData service.
I have created a SAP cloud platform Cockpit trial account and created a destination for my in house development gateway.
When I click on test connection, it shows host not found: 502.
I am not able to access oData connection url without saml2=disabled parameter, so tried with Basic authentication using my SAP user.
SAP is on Azure cloud. What am I missing here?
Based on your hardware landscape you might need to configure SAP Cloud Connector,
as documented here:
“The Cloud Connector serves as a link between SAP Cloud Platform applications and on-premise systems. It combines an easy setup with a clear configuration of the systems that are exposed to the SAP Cloud Platform. You can also control the resources available for the cloud applications in those systems. Thus, you can benefit from your existing assets without exposing the whole internal landscape.
The Cloud Connector runs as on-premise agent in a secured network and acts as a reverse invoke proxy between the on-premise network and SAP Cloud Platform. Due to its reverse invoke support, you don't need to configure the on-premise firewall to allow external access from the cloud to internal systems.”
And also look here:
“If your remote system resides behind a firewall (proxy type OnPremise), the following prerequisites must be met:
You have set up Cloud Connector and defined a virtual host mapping for the system.”
Also take a look here:
“Maintain Destinations for SAP Cloud Platform Connector
In the SAP Cloud Platform Cockpit, maintain destinations for each target system to enable communication via the SAP Cloud Platform Connector.
For on premise systems, make sure to select the Proxy Type OnPremise.”
I also faced a similar issue yesterday night. This generally has to do with some config problems.
For me, it was the Proxy settings. it was set to 'Internet'.
It had to be set to 'OnPremise'. After doing that, it got successfully connected.
I understand that to access a company that is not currently open in QuickBooks, the web service needs to supply QuickBooks Web Connector with the file location as a return value to an authenticate() call.
This seems backwards to me. Why would the web service be in charge of telling the Web Connector where the relevant company file is? Wouldn't it make more sense for it to be managed by the Web Connector?
Here's the relevant explanation I've found within the QuickBooks Web Connector
Programmer’s Guide:
IF your web service wants to try a different company, supply the company pathname in the returned string. (You can supply an empty string if you want to use whatever company file happens to be open.) The web connector will respond by attempting to connect to QuickBooks again using that supplied string.
Why Would a Web Service Try a Different Company?
Why would a web service perform the second of these actions instead of simply just stopping altogether? In practice this approach is used when the web service remembers the company file path from session to session (a recommended practice) and wants to have a fall-back to use whatever company file is currently open in QuickBooks (by responding to the connectionError call with an empty string).
This is not as haphazard as it might seem. When a web service is added to the web connector, the web connector stores a unique FileID as a private data extension in the specified company. As a result, the web service can always verify that it is talking to the expected company file simply by checking the CompanyRet returned to your web service in the web connector’s first sendRequestXML call in the data exchange sequence. (Check the data extension list for the expected FileID.)
This seems like a poor end-user experience; if they move their company file (assuming they want the Web Connector operate without QuickBooks open), the web service will fail until that path is updated on the server side. It seems totally plausible that an end-user could do this without knowing it would break things.
Why is it structured this way? And more importantly: is there a way around this?
Why is it structured this way?
Because this is how Intuit built it.
is there a way around this?
No.
I have been playing around with the RPC package in Dart which makes it easy to add a Document Discovery service to Dart server.
After a bit of Googling I found out about the API Discovery Service https://developers.google.com/discovery/ which explained how to create client code for a given Discovery Document.
I then found Google Cloud Endpoint which looks like the server end of the a Document Discovery service. Is this true.
My real question is that I would like to use the Document Discovery service on a standard web site that is based on (say) Spring and running (say) an embedded Jetty server? Is this possible or would my application be intertwined with the App Engine Technology?
You application just needs to provide a Document Discovery service.
It shouldn't be to hard to get the information what is expected out of the source of https://pub.dartlang.org/packages/discovery_api_client_generator which is the Dart client which generates Dart client code from discovery documents. As far as I know your service doesn't even need to provide the discovery documents. The discovery_api_client_generator package can also use discovery documents stored locally but the service is of course the preferred way if you want to make it available to everyone.
I would see it as equivalent to SOAP which also allows to create client code from meta-information provided as XML.
Also the shelf_rpc package doesn't need to run on AppEngine or Managed VM. You can run it locally or on any server you want.