We are trying to setup Linked Service for the SAP ECC connection within the Azure Data Factory. One of the required properties is "URL" which we are not sure how to format it (please see the attached screenshot). Is this an SAP server name? We need to connect multiple tables/views (approx. 150 of them). Do we need to use separate URL for each table/view?
Is this an SAP server name?
At the place of URL, we need to enter the URL of the SAP ECC OData service.
You must expose the SAP ECC entities via OData services through SAP Gateway in order to utilize this connector or linked service for SAP ECC.
For exposing SAP ECC data through OData services Building a service is a fairly common use case for SAP NetWeaver Gateway. With the TCODE SICF you to instantly activate the OData service. The objects that must be exposed can also be configured.
see this step-by-step guidance to build an OData Service blog by Volker Drees.
Example (SAP ECC OData URL):
http://eccsvrname:8000/sap/opu/odata/sap/zgw100_dd02l_so_srv/
Reference: https://learn.microsoft.com/en-us/azure/data-factory/connector-sap-ecc?tabs=data-factory
Related
On an on-premise we have option to call BAPI for CRUD operations. How can we achieve the same in SAP cloud environment. For example I am trying to find solution to post FI documents from external API into SAP Cloud, equivalent to bapi_acc_document_post in on-premise.
Thanks.
In Cloud Environment you can enable SAP API Business Hub to access APIs described in api.sap.com
There are several APIs available for different SAP Applications; for example check Journal Entry - Post (Asynchronous)
You can find a Business documentation describing the use cases from a functional perspective as well as technical informations (API Specs, WSDL, urls etc..)
Here is the situation :
I have a partner service outside of my network. This service is a legacy one, using soap. My internal app needs to fetch data from this service but I don't wan't to work with soap/json. My first reflex is to expose this service on my internal API gateway to consume it but ...
My gateway can of course manage transformation Rest/soap but I want to avoid doing transformation on the gateway as it is resources and time expensive.
I think of a facade component inside my network but this component will have to access public network directly and I feel this is not right.
What can I do ? Isn't it an anti pattern to get out of my network by another door than the gateway ?
there are two type of gateway
1- API gateway : which is for clients and users who need to use your APIs
2- Service gateway : in SOA or MSA your services should not call external services directly (for security reasons and also for decoupling them from each other , maybe one of them working with REST and other one working with SOAP which is your case) rather you should use something which called integration services (integration frameworks) or ESBs (enterprise service bus).
Your problem is you want to use your API gateway instead of service gateway.
Keep your API gateway for your clients but if your services need to call external services use an integration framework or a service bus.
One of the most main features of these tools is that they can convert protocols together for example they have convertors to convert SOAP to REST , it means you call it by REST but it will convert your call to SOAP and call the external service ( you just should config it to which protocol it should convert ).
And also there are many ready to use connectors in them which can connect your service bus to other applications and services like DBs, messaging platforms , linkedIn , ...... .
There are many ready to use ESBs like Apache camel , Mule ESB and .... .
I have a query on a design hope you guys can clarify my doubt.
I have a specific requirement in which Mule is used just to expose the back end services in API gateway, backend services are written in Spring boot and other technology, all these services needs to be exposed in API gateway.
Is this a good practice to do that and if yes how can we do that?
I saw that in API manager we can create proxy layer on top of the services developed in Mule but is it possible to create proxies for the services developed in different technologies?
Absolutely ... For creating proxy service, it doesn't matter what type of technology does the backend service have.
It can create a proxy layer for any kind of backend service available either locally, in cloud or other remote location till the service url is accessible.
This proxy will create an additional layer hiding the actual url to the external world.
it doesn't matter what technology you are using for development as long as those are REST services and accessible to the cloudhub application. You can deploy those on-premise and can integrate your local runtime with cloudhub. Also, mule supports spring projects and you can directly configure your spring project/details inside mule.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
What is the difference between SAP Netweaver Gateway and SAP JCo Adapters ?
SAP Netweaver Gateway Adapter:
IBM MobileFirst Platform Foundation applications can communicate with SAP Netweaver Gateway back-end services by using SAP adapters. Using HTTP rest calls and the OData protocol, applications can remotely create, retrieve, update, and delete entities through the adapter.
No additional middleware required to communicate with SAP system.
SAP JCo Adapter:
The SAP Java Connector (SAP JCo) is a middleware component that enables the development of SAP-compatible components and applications in Java.
Correct me if I am wrong.
The Service Discovery for SAP NetWeaver support enables the ability to codelessly generate MFP Adapters through exploring SAP sources and altering response data from SAP, through their Gateway product. Gateway is an extra layer of SAP middleware. For clients that have Gateway as part of their topology, this is a solid tool for generating custom mobile services.
The MFP JCo adapter provides support for writing custom implementation of service creation. This solution requires custom coding, using the JCo APIs, but is available for all SAP installations.
Summary, they are different animals that solve the same problem, in dramatically different way. Hope this helps.