We are trying to communicate with SAP R/3 from a standalone java application
We will use the JCo 3.0 libraries for this.
From the documentation I understood that there are 2 ways to connect with SAP.
as a JCo Client
as a JCo Server
At first I was convinced that our application would need to connect as a JCo client. But I am starting to doubt.
Our application sends data. (e.g. update of order status)
But our application also receives data (e.g. SAP pushes changes to the master data - MATMAS).
So, does it need to be a client or a server ?
There is no JCo Client in the JCo 3.0 API model but only JCoDestinations instead which replaced the old JCO.Client from the 2.1 API model.
And the 2 ways to connect to SAP via the RFC protocol are:
Inbound RFC communication (as an RFC client / Java calls ABAP)
Outbound RFC communication (as an RFC server / ABAP calls Java)
For inbound RFCs you need to use a JCoDestination for executing a remote function module at ABAP side. For outbound RFCs you need to register a JCoServer at the SAP gateway which will then receive incoming requests from ABAP side in order to process a remote function module at Java side.
In both communication directions there is a request and potentially also a response to this request, so the data flow is in both directions for inbound and outbound RFC communication. Inbound and outbound just distinguishes who initiates the RFC call.
And regarding the JCoServer, you usually also need to define some JCoDestination as well for a repository, because this is needed by a default JCoServer for querying required RFC metadata from an ABAP back-end. Without such a JCoRepository, a JCoServer would not be able to interpret the incoming RFC request data. So in a typical JCo server scenario you need both: a JCoServer and a JCoDestination (for the server's JCoRepository).
You can use the same configuration for the JCoDestination for both use cases (client calls and repository queries), but SAP recommends to define separate configurations which is more flexible regarding the definition of connection pool sizes and allows separate RFC authorizations for both use cases.
Both. Actually, you need a client connection to initiate a server connection, so when you setup the server connect, you'll automatically get the client connection as well.
Related
How to establish a connection to SAP EP (portal) from Java application using JCO?
We are able to connect to ABAP system but not able to get more info to establish connection to SAP PORTAL and read UME users.
SAP does not recommend to use the proprietary RFC protocol for connecting two non-ABAP systems with each other, but to use other standard protocols like HTTPS for this instead.
However, if you would like to use JCo nevertheless, connecting a standalone JCo application to a NetWeaver AS Java instance (like the Enterprise Portal) would then be a so-called extern-to-extern RFC communication. A direct point-to-point communication is not possible via RFC and you will also need a third component, namely a SAP gateway, which serves as a "meeting point" for both RFC communication partners.
Please see the following SAP Notes for the required special configuration steps at each side:
SAP Note 1877907 - Support of extern-to-extern RFC communication with
JCo 3.0
SAP Note 1729203 - Support for communication with external
RFC server
SAP Note 1717833 - RFC destinations to support external
RFC servers
This was only the technical aspect of the RFC communication. Of course, you then need to implement the client side RFC calls and the RFC server side with offering appropriate Remote Function Modules that provide the desired functionality.
I don't think that such an RFM for reading UME users at the NetWeaver AS Java side is already available out-of-the-box.
I will be having a software which will give me information about the moving vehicles on the server side and I need to pass this information to the client computer on demand.
There will be a website which will act like a server and another website will act like a client. The client
website will ask for a data from the server website.
From here: https://stackoverflow.com/a/2849683/462608
As the protocol may not be HTTP, you may provide WebServices over mail or other protocols, and you do not need a web server for that.
I request an explanation on the above quote. In my case will I be needing a webserver?
There is a bunch of webservice protocols, some of them may use and some may not use http as transport layer. When http is used - you need a webserver on server-side of your service and a webbrowser as a client. If the transport is other than http, you need server of other type, and other client, for example, mail server and mail client in case of running service over smtp.
I have two computer systems each having an apache server. One machine is a client machine and the other is a server machine. I want both the client request and the server response to be encrypted thus making the data transfer safe.
Could someone please give pointers/steps on how I could make progress in this front.
The communication doesn't involve any GUI components meaning the communication is purely a backend one.
Both the client and the server are coded in java. I am using Axis2 and jaxws for the communication.
Currently I am able to send the client request and receive the server response without SSL enabled. Now If I enable SSL does it mean that I should also modify the existing code according to the SSL or the current working code still holds good.
You have many options here. Since you mention SSL...
On each server generate an asymmetric key-pair (RSA 2048 is a safe choice). Then create a self signed certificate on each server. Then copy each certificate to the other machine and mark it as trusted by the Java environment that apache is using and that NONE OTHER are trusted. Configure SSL/TLS on each of the apaches to use a good symmetric cypher (3DES is a safe choice, but there are other newer ciphers if you want leading edge). Next ensure that all access between Tomcat servers is via https URLs and you should be in decent shape.
An alternative is to use IPSEC to establish a static tunnel between the two servers using certificates or other trust bases.
One fairly simple option is to use stunnel, which is available via the standard package-manager on most *NIX systems. You configure an stunnel as a client (and server if you with) on one server and then another as the server (and client if you wish) and then configure your Tomcat instance(s) to connect to localhost:XYZ where XYZ is the port where stunnel is listening.
The nice part about using stunnel is that you can use it to tunnel any protocol: it is neither a Tomcat-specific nor a Java-specific technique, so you can use it for other applications in the same environment if you want.
I need a system in which I can send SOAP request to 1 server from a few and then if server has this service it calls and returns value to client.
If not it passes the request to next server on his "list of neighbors". Request is passed until some server has needed service (or not, so we return error result).
My question is. What will be the best way to communicate between those servers. SOAP? Message Driven?
It will be great If it could work without central server. If I will use MD, should not all servers use common JMS on some central server?
Is it possible to send MD to specific server on given address?
Take a look at Apache ActiveMQ or Apache Camel or Spring Remoting
I am pretty new to security aspect of application. I have a C++ window service (server) that listens to a particular port for http requests. The http requests can be made via ajax or C# client. Due to some scope change now we have to secure this communication between the clients and custom server written in C++.
Therefore i am looking for options to secure this communication. Can someone help me out with the possible approaches i can take to achieve this.
Thanks
Dpak
Given that you have an existing HTTP server (non-IIS) and you want to implement HTTPS (which is easy to screw up and hard to get right), you have a couple of options:
Rewrite your server as a COM object, and then put together an IIS webservice that calls your COM object to implement the webservice. With this done, you can then configure IIS to provide your webservice via HTTP and HTTPS.
Install a proxy server (Internet Security and Acceleration Server or Apache with mod_proxy) on the same host as your existing server and setup the proxy server to listen via HTTPS and then reverse proxy the requests to your service.
The second option requires little to no changes to your application; the first option is the better long-term architectural move.
Use HTTPS.
A good toolkit for securing your communication channel is OpenSSL.
That said, even with a toolkit, there are plenty of ways to make mistakes when implementing your security layer that can leave your data open to attack. You should consider using an existing https server and having it forward the requests to your server on the loopback channel.
It's reasonably easy to do this using either OpenSSL or Microsoft's SChannel SSPI interface.
How complex it is for you depends on how you've structured your server. If it's a traditional style BSD sockets 'select' type server then it should be fairly straight forward to take the examples from either OpenSSL or SChannel and get something working pretty quickly.
If you're using a more complex server design (async sockets, IOCP, etc) then it's a bit more work as the examples don't tend to show these things. I wrote an article for Windows Developer Magazine back in 2002 which is available here which shows how to use OpenSSL with async sockets and this code can be used to work with overlapped I/O and IOCP based servers if you need to.