We are planning to use Sync Services for ADO.NET to sync stores with headoffice and it has been suggested that I sync via a WCF proxy.
Does syncing via a WCF proxy mean that I will be able to sync over http? If not, is it possible to use sync services to sync via http.
(I do not want to update our firewall every time we get a new store that needs to sync with the headoffice -- that is why I want to sync via http).
Yes, WCF implments both SOAP and REST webservices, either can which can be exposed over http or http/s.
Here's some documentation from MSDN on WCF.
We always use http/s (SSL), even inside our LAN.
Related
I've created a SOAP Service in ABAP, which perfectly works inside the network.
Now I wan't it to be called from outside and I haven't really found any tutorial.
Most likely a SAP Web Dispatcher or a reverse proxy is required, but how to use them?
Or is there an easier way to make the endpoint "public" and callable from the "outside"?
Making it public not part of SAP system. You need to configure your network to allow incoming request. Generally you need to configure your firewall. You need to open a port on firewall and redirect it to your SAP server http/https port. It will also create a risk for opening http/https port to outside. You must sure about limit your your web service user authorizations and changing all default passwords and using update date SAP system for security patchs.
For more get security I prefer to use a proxy server like nginx/apache to just serve your SOAP service over it.
Usually it is done thourgh reverse-proxies, to minimize risk of attacks from public Internet.
The general schema looks the same, although there are multiple variations depending on the company
The oldest and the most traditional reverse-proxy for SAP systems is a Web Dispatcher
SAP Web Dispatcher it includes load balancing and HTTP filtering
https://informatik.rub.de/wp-content/uploads/2021/11/2_sap-secure-configuration.pdf
https://wiki.scn.sap.com/wiki/display/SI/FAQ+Web+Dispatcher
https://blogs.sap.com/2021/05/09/landscape-architecture-sap-web-dispatcher-deployment/
SAP Gateway is a framework for exposing functionality as REST/SOAP web-services
https://blogs.sap.com/2018/04/15/sap-odata-service-get-consume-rest-service/
The tutorial for configuring SAP Web Dispatcher + SAP Gateway together
https://help.sap.com/saphelp_uiaddon10/helpdata/en/ec/342f1809c94d2b817ba772fe69e43f/content.htm?no_cache=true
The other options for reverse-proxy for SAP:
nginx
Apache
...
You are free to choose any reverse proxy on the market depending on your environment.
I've installed WSO2 Api Manager 4.0.0 on internal server and I have no idea how to tell it to use proxy server to connect to Choreo analytics.
I see following error in the log:
:Provided authentication endpoint https://analytics-event-auth.choreo.dev/auth/v1 is not reachable.
I've tried to set http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY environment variables with flag java.net.useSystemProxies=true to api_manager.sh but they seem to not work and I don't see any traffic coming from this server through proxy.
Adding java flags http.proxyHost and http.proxyPort didn't helped too.
If I start it from server with internet access then it works just fine with Choreo.
Is there any way to set the proxy for APIM?
WSO2 API Manager's gateway component talks to an API in the Analytics cloud in order to fetch required credentials to publish events to the cloud. The failure that you have pointed out occurs at the point of talking to this API. It appears that proxy settings have not been configured for this particular HTTP client. Please see here.
Event publishing is the next step and uses AMQP protocol. Therefore I think it would not go through the HTTP/S proxy. However, if the gateway has no access to the internet, this step will fail again regardless of the API call is fixed to honour the proxy settings.
Currently, analytics does not have the support to publish events through a proxy. It seems that in order to honour proxy settings in event publishing, the protocol needs to be changed to Websocket.
I want to map an API Gateway endpoint with a Socket.io server endpoint, in order to authenticate users through Cognito and, if successful, redirect to the Socket.io server and establish a socket with optional namespace and rooms.
Is that makes sense? I didn't found any example, and API Gateway has only recently enabled a WebSocket API but without support for Socket.io
Your question has two parts:
First, the API Gateway using Cognito to authenticate your client;
Second, assuming you are using an EC2 running Node.JS with Socket.IO using API Gateway as an endpoint for your clients.
For the First part, you may use the following reference from AWS documentation.
There are several sub-parts when you talk about AWS Cognito, for example including AIM permissions Method Execution to enable API resource endpoint HTTP method.
For the second point, enable API Gateway to establish a synchronous connection with EC2 port running Socket.io you may read some references like this one.
You should configure your API Gateway:
Protocol WebSocket connection
Select your Route Selection expression ,e.g. \$default
Map the target backend for each $connect, $disconnect and $default
Use integration type AWS Service
Select EC2 and fill the rest of configs.
The answer by Rafael focuses more on using the Websocket API Gateway which in my opinion is still relatively new and there is some space to improvements. Plus I don't like having lambda integrations with database access because without RDS proxy they exceed the db connections really fast, and I don't think HTTP integration adds anything to the whole thing because you're performing HTTP request in the end but it's called through the Websocket API.
One thing I agree on with Rafael is that you need to have an EC2 instance running socket.io whether it's in Node.js or python (I used python with Flask in my case).
I managed to connect to my socket.io by using the HTTP API Gateway and setting allow_upgrades=False so http protocol won't be upgraded to ws protocol, because HTTP API Gateway doesn't support ws. My HTTP API Gateway is just forwarding socket.io requests to the load balancer, and good thing about that is that you can define access control on each route defined in the HTTP API Gateway.
The socket.io on my EC2 instance is defined like this:
socketio = SocketIO(async_handlers=True, allow_upgrades=False, cors_allowed_origins='*')
And my client connects to it by simply calling the route defined in the HTTP API Gateway which has proxy integration enabled.
https://xxxxxxxxx.execute-api.us-west-2.amazonaws.com/socket.io/{proxy}
Final result - client connected to socket
Before websocket technology, if you wanted real-time data in your browser, you needed a wasteful polling strategy. That's why websocket technology was introduced. However, it took some time before browsers supported it. On top of that, it wasn't that good at handling reconnects.
Socket-io gave us early-access to a reliable solution by combining multiple protocols, and adding several features to improve the stability and to recover from errors. With new releases, the protocol changed, and more flags and options were added.
That evolution made socket-io what it is today, which isn't exactly an "open standard". For that reason, it will probably never be decently supported on AWS.
Some possible solutions:
Having said that, browsers have evolved and most of them support websockets now. So, you could consider to migrate (back) from socket-io to plain old websockets. Nevertheless, you probably want to add a "heartbeat" that sends back and forth ping/pong messages to detect disconnects (which is one of those things that socket-io has built-in).
However, if you like GraphQL, then you should certainly consider AWS AppSync, which amongst others supports GraphQL subscriptions to push notifications to the client. Apollo client is extremely popular and reliable.
I am trying to create a clustered cache service for Cloud Foundry. I understand that I need to implement Service Broker API. However, I want this service to be clustered, and in the Cloud Foundry environment. As you know, container to container connection (TCP) is not supported yet, I don't want to host my backend in another environment.
Basically my question is almost same as this one: http://grokbase.com/t/cloudfoundry.org/vcap-dev/142mvn6y2f/distributed-caches-how-to-make-it-work-multicast
And I am trying to achieve this solution he adviced:
B) is to create a CF Service by implementing the Service Broker API as
some of the examples show at the bottom of this doc page [1] .
services have no inherant network restrictions. so you could have a CF
Caching Service that uses multicast in the cluster, then you would
have local cache clients on your apps that could connect to this
cluster using outbound protocols like TCP.
First of all, where does this service live? In the DEA? Will backend implementation be in the broker itself? How can I implement the backend for scaling the cluster, start the same service broker over again?
Second and another really important question is, how do the other services work if TCP connection is not allowed for apps? For example, how does a MySQL service communicates with the app?
There are a few different ways to solve this, the more robust the solution, the more complicated.
The simplest solution is to have a fixed number of backend cache servers, each with their own distinct route, and let your client applications implement (HTTP) multicast to these routes at the application layer. If you want the backend cache servers to run as CF applications, then for now, all solutions will require something to perform the HTTP multicast logic at the application layer.
The next step would be to introduce an intermediate service broker, so that your client apps can all just bind to the one service to get the list of routes of the backend cache servers. So you would deploy the backends, then deploy your service broker API instances with the knowledge of the backends, and then when client apps bind they will get this information in the user-provided service metadata.
What happens when you want to scale the backends up or down? You can then get more sophisticated, where the backends are basically registering themselves with some sort of central metadata/config/discovery service, and your client apps bind to this service and can periodically query it for live updates of the cache server list.
You could alternatively move the multicast logic into a single (clustered) service, so:
backend caches register with the config/metadata/discovery service
multicaster periodically queries the discovery service for list of cache server routes
client apps make requests to the multicaster service
One difficulty is in implementing the metadata service if you're doing it yourself. If you want it clustered, you need to implement a highly-available-ish consistent-ish datastore, it's almost the original problem you're solving except the service handles replicating data to all nodes in the cluster, so you don't have to multicast.
You can look at https://github.com/cloudfoundry-samples/github-service-broker-ruby for an example service broker that runs as a CF application.
The NServiceBus Web service bridge example only demonstrates a Command message scenario. I am interested in a scenario where the web service bridge uses request/reply to do a synchronous response to the client like any other normal web service call. In other words, can I use the web service bridge to create a web service that does the following things
expose a synchronous method e.g. ClassA process(ClassB objectB) via the web service interface
Behind the scenes call various ascynhronous services hosted as NServicebus services.
When I get all my replies back, synchronously respond with a ClassA object to the web service client
Any help is appreciated.
NSB will only allow for the return of an error code(enum) when you expose your endpoint as a web service. This is by design as all communication is meant to be unidirectional to avoid temporal coupling(process A has to wait for process B)