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.
Related
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.
I am going through a Computer Networking books that defines Internet API as the "set of rules" defined by Internet through which data is transferred from one end-user to another. Protocols are again defined in the very same manner, but it makes me a bit confused as what exactly the main difference between them is.
The book is computer networking by James F. KUROSE and KEITH W.Rose.
In one of the paragraph it says that "The internet API is a set of rules that a sending program must follow so that Internet can deliver the data to the destination".
Now for Google, Internet Protocols is "A set of rules governing the format of data sent over the Internet or other network."
Both of them can't be wrong. There is one point that I am missing.
Please Help.
API stands for Application Programming Interface, it referes to methods, data, and rules to interact with a component from an application you are programming. If somebody says Internet API it might refer to a set of methods, data and rules you must consider in your application. I don't know of a generic "Internet API" ... The definition for Protocol you can find it in Wikipedia (also for API). A protocol includes definitions for message format, data flows, and sometimes algorithms that let two entities communicate with each other. A Protocol defines the way two entities communicate, a protocol API is an interface for an application to use a protocol implementation. I hope this helps, I don't agree with such concept as "Internet API" and I think the definition of protocol that you found is incomplete.
I have been reading the same book and what i understand is that, a protocol is much standardized set of rules they are very low level instructions.
An API on the other hand comes in a picture at a much higher level.
An API must in an itself contain various internet protocols to communicate.
A protocol is like a package delivery, but an API is like a letter delivery(content specific)
Any content can be sent over a protocol, but only well defined info can be sent over an API.
picture this a protocol transmits raw data, an API transmits processed information.
API are meant for programming, with APIs you can communicate with some application component to collect data/edit/restrict... those APIs like REST for example use the protocol HTTP/HTTPS requests and responses, it also uses TLS/SSL protocols for security transport.
Protocols is meant for communication between DEVICES, API communicated between APPLICATIONS.
I hope you make use of those paragraphs below :
#HTTP is a communication protocol with a given mechanism for server-client data transfer. It's most commonly used in REST API just because REST was inspired by WWW (world wide web) which largely used HTTP before REST was defined, so it's easier to implement REST API style with HTTP.
#A HTTP API is ANY API that makes use of HTTP as their transfer protocol. This means that even SOAP can be considered a HTTP API, as long as it will use HTTP for transport, but most HTTP APIs will make more and better use of the infrastructure and possibilities of HTTP.
#HTTP APIs make it easier to create APIs with the most common functionalities required to create serverless apps or to proxy requests to HTTP endpoints. They provide features like throttling, metrics, and logging that are typical in API Gateways.
I am new to services. I am sorry for my question being a little theoretical. On a site I was reading about SOAP, they said it works over internet.
Can we use SOAP based services in intranet environment ?
Can we use HTTP over intranet or it is just a internet protocol ?
Please guide.
You can use SOAP over any TCP network. This could be internet or intranet. SOAP is an interoperable protocol over HTTP. And HTTP works over TCP. So everywhere you have HTTP you can have SOAP. Basically SOAP is a protocol which allows for heterogeneous systems to communicate using an industry defined standards.
And note that SOAP is getting less attention lately compared to REST which is starting to gain lots of momentum.
SOAP is a service supported by a server/web service. You can even use SOAP to translate data between two services on the same server box that have no other form of API.
I am working private network.This alread developped product which implemented using TCP(client server technology).
Existing product is as follows
There is a UI which is developed using flex, where user can see video or snapshot
There is a server which is developed using c++,which redirects request from UI to gateway.
There is gateway which is connected with the Camera,which stream video to UI through server.
Now we wanted to add p2p technology to existing client server.So it will support TCP as Well As UDP.
Presently we are exploring flex and XMPP to implement the p2p.
as newer version flex of flex support p2p using RTMFP, but thats the propriety protocol of adobe.if we use RTMFP we need to change all the existing code that we dont want
I wanted to implemented to p2p using flex client(UI) which will use XMPP to communicate with Gateway and Server.
So the question is
Is it possible to use XMPP from flex code
Will XMPP support UDP p2p or not.
Yes. You can use the as3xmpp library to communicate to servers using that protocol.
To my knowledge, no. My understanding is that the network protocol used in p2p connections is internalized, and doesn't allow for public APIs to define their own network protocol (unlike Sockets for example).
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.