I am managing a web application which have to be integrated with other systems such as SAP/Oracle ERP. I am pretty familiar with the middleware method of data integration where I use my stored procedures to read/write data from/to the middleware database and the other system(SAP/Oracle ERP,etc) use their methods or custom applications to read/write their data from/to the middleware DB.
Now I know that these companies like SAP have their own API for integration.So i want to understand how does API based integrations work. Can you guys please help ?.
One of the best resources for SAP integration is the SAP API Business Hub: https://api.sap.com/. You can use it to search for predefined APIs that are available within the SAP system. To use these APIs, you will need to configure and activate them in the SAP system. These predefined solutions are designed to be used for a particular business process. For instance, to send/receive employee data for HR records, or to send/receive purchase orders. SAP aims to provide sufficient APIs that almost any integration needs can be met with their predefined solutions.
Regarding the types of API solutions SAP uses, SAP allows for the creation and consumption of OData, an open protocol for REST based APIs. This blog series contains a good introduction to how OData is used in SAP: https://blogs.sap.com/2016/02/08/odata-everything-that-you-need-to-know-part-1/. OData uses HTTP requests, so the two systems can interact using the standard CRUD operations (create, read, update, delete). Two important transaction codes to work with IDocs are:
SEGW (gateway service builder): create OData services
/IWFND/MAINT_SERVICE (activate and maintain services): activate and query the services
In addition to this, as you mentioned, SAP has its own API technologies. Two key SAP technologies for integration are:
IDoc (Intermediate Documents):
This is a document format that you can use to send data to external systems (outbound) and receive data from external systems (inbound).
You set up partner profiles for the system you are sending data to (t code WE20).
There are predefined IDoc types that define the data contained in the IDoc (this is the 'basic type' and 'message type'). IDoc data is organised into segments and, for a given IDoc type, you can append the segments so that only the specific data you require is sent.
You will need to map the data structure from the outbound and inbound systems using your middleware.
For a detailed guide to IDocs I strongly recommend the ALE (application link enabling) e-book on the SAP Learning Hub if you have access. You can use t code WEDI to browse the relevant ALE t codes.
BAPI (Business Application Programming Interfaces):
These are similar to function modules, but, unlike function modules, they can be called remotely. Like IDocs, they use RFC (remote function call).
BAPIs can be executed using SE37. You need to set up a test sequence (Test -> Test Sequences) because BAPIs do not automatically commit. Give the name of the BAPI, then 'BAPI_TRANSACTION_COMMIT'. Then execute the sequence to use the BAPI.
Many pre-existing BAPIs are already in SAP. You can browse them using t code 'BAPI' (BAPI Explorer).
Please see this guide for further information on BAPIs and for instructions to make your own BAPI from scratch. https://www.guru99.com/all-about-bapi.html
Related
I´m trying to create a new Charge/Credit into my system SAP Bussiness Bydesing, but I did not find and object inside the repository explorer in the SDK neather a Webservice, can you tell me if its possible to access this view via code or using an Odata or a Webservice?,
I have tried accessing via Payables, Supplier Account, Reciables, Customer Account, but i did not find anything that allows me to modify or create a new charge/credit.
Thank you in advance.
Regards.
You are right, there are only few SAP Business ByDesign APIs in the API Hub. However; SAP Business ByDesign offers the possibility to generate custom OData APIs out of the business documents such as sales order, purchase order, supplier invoice, customer invoice, product master data and business partner master data. The custom OData APIs can then be used to build extension applications – among others - in SAP cloud platform using SAP Cloud SDK. Here are some reference materials that can help you in the creation and consumption of SAP Business ByDesign Custom OData APIs:
You can find examples and descriptions in the following GitHub
repository:
https://github.com/SAP-samples/sapbydesign-api-samples
The following video clip will guide you on how to generate custom
OData APIs on SAP Business ByDesign:
https://www.youtube.com/watch?v=z6mF_1hFths
You can refer to my blog post series on how to consume SAP Business
ByDesign custom OData APIs in SAP Cloud Platform using SAP Cloud SDK.
https://blogs.sap.com/2019/02/03/sap-business-bydesign-side-by-side-extensions/
A quick search found the following blog post about SAP Business ByDesign: OData API Examples.
If there is an exposed OData Service, then you can create an OData VDM with the SAP Cloud SDK.
Alternatively you can take a look into the dedicated entry in the SAP API Business Hub. There are some SOAP services listed. If one fits your needs, then you can consider using the SAP Cloud SDK to invoke SOAP requests (or use any other client to do so).
You can also reach out to the colleagues who maintain the project. Maybe they offer a well maintained OData specification somewhere.
I need to use multiple APIs from multiple sources in my new website. They are all similar in functionality but with some differences in format. Then I need to build some type of proxy to make them all the same before use.
Can I use an API Management solution like WSO2 to integrate all these APIs and standardize them as a single API?
Is there another solution for this?
Thanks
You are actually looking for an integration solution. Therefore, what suits best is the WSO2 Enterprise Integrator. You can write a couple of Synapse code to combine a set of APIs and expose them as one.
Now, if you need to enforce policies such as authentication, authorization, rate-limiting etc. (i.e. if you need to expose this API as a managed API), then only you need APIM in front of it.
Kloudless provides an abstraction layer via a single unified API to connect to several third-party APIs without having to implement code for each of them. In that way, it functions as a proxy for all those third-party APIs and abstracts out data models, authentication, error-handling and rate-limiting, and more. (I'm a co-founder)
Use Wso2 Enterprise Integrator where You can create API and Apply the various integration patterns to achieve your requirement. Then if you need you can publish the same in API management.
ESB requirement:
You can use either a management console for creating API's or an eclipse designer extension from wso2. For creating API's XML knowledge is enough otherwise it also provides drag and drop feature.You don't require JAVA knowledge as the inbuilt mediators which are shipped with Wso2 ESB is enough. But if you have knowledge of java then you can create custom meditaors(mediators are used for creating busniess logic) incase of some special needs. If you don't know JAVA then you can use Javascript, Ruby, Groovy inside script mediator. I prefer for smaller transformation I will use Script mediator if you have larger message size then you can go with class mediator that's where we'll use JAVA. This is all the requirement you need for ESB.
Technologies required for ESB: XML, XPATH, JsonPath, XSLT, Xquery , scripting knowledge(Javascript, Ruby, Groovy)etc.
If you are beginner then please refer this tutorial https://docs.wso2.com/display/EI640/Integration+Tutorials
For API management programming knowledge not required.
The definition of an API seems very broad and I don't understand whether an API is the link that connects different software or whether the server that provides data like how a airport company provides fight information to a website is the API.
Could it be both?
It can be both. In practical terms, the most common way two pieces of software interact with each other is through APIs. The two pieces of software might be living on the same computer (e.g. an App using services provided by the OS). They can also be running on different computers separated by internet.
APIs often consist of classes and methods/functions. For a given API method/function, in general it does one or more of these 3 things:
retrieve information
store/update information
perform an operation
For example, an airport company runs a server exposing REST APIs that provide flight information. A client (e.g. a smartphone app) calls that REST API to retrieve flight information.
API spec defines a contract - the exact semantics on how caller calls the API. e.g. method names, parameter types and expected values.
Kindly, can anyone differentiate between System api and Process api?
Please provide answer in Generic terms, as i am unable to find on internet.
A system api abstracts from an existing system. It talks to the system in the language of the system (e.g. SOAP, direct Java calls, SAP calls, etc.). To the outside world it offers a clean API (usually REST with http and json). When you do a good job implementing your system api, you can exchange your existing system with a different/new one without changing the api of your system api to the outside world: Just implement a new system api with different adapter logic.
A process api should talk REST on "both ends". It calls one or several system apis to do its job. The process api orchestrates different jobs.
When you need more information, do a search with "api led connectivity"
A System API is a layer you build on top of a system, which handles all system specific connection quirks and settings. It then exposes these resources and it's logic in a standard format (usualy REST but you're free to choose something else like SOAP) to the rest of your API's. Like Roger Butenuth states:
"When you do a good job implementing your system api, you can exchange
your existing system with a different/new one without changing the api
of your system api to the outside world: Just implement a new system
api with different adapter logic."
A process API is where you keep your logic and orchestration, it does not 'talk' to end systems directly but instead connects to system API's to get it's data.
A process API should idealy only talk REST on both sides and can aggegrate data from multiple systems.
An example of a complex process API would be an "items you've ordered" API which takes in a user id as it's input, then talks to the system API of a CRM system to get the id used by the "order history system API".
However this API might only return a list of orders without any article information besides an article id. So our Process API then enriches this list with Article information fetched from "article information system API" with the id from the list.
I know it's out of the scope of the question, but for the sake of completeness i'l shortly explain the third variant as well:
An Experience API can be seen as a doorway into your API network, every (type of) client has different information needs and can communicate in different protocols.
It is the Experience API's responsibility to provide ALL the information required by a client in a format they support.
This takes the responsibility away from a client to know where the information needs to be fetched from.
(Customer info from CRM, Order info from proprietary sys one, Article info from article DB)
This concept of design has as a bonus that if when for example, the mobile app your company is making, gets some new functionality which requires extra data.
You can update the "mobille app experience api", which would leave your "superexpensive IBM Experience api" unchanged. Cutting down on development costs as you don't need to implement any changes in your other api consumers which would be the case had you had only one api.
I think the main difference is where you are implementing business process and rules/logics.
System API, within the scope of your design, are atomic APIs which will be used to construct higher level API (experience APIs). Process API is the orchestration layer where you can use Mulesoft flows to implement business process or logic.
System APIs do the heavy lifting work of CRUD operations.
Process APIs focus on business logic
System API's are underlying all IT designs are center frameworks of records that are regularly not promptly accessible because of its many-sided quality and network concerns. APIs give a method for concealing that many-sided quality from the client while uncovering information and giving downstream protection from any interface changes or legitimization of those frameworks.
Process APIs exemplify the fundamental business forms that cooperate with source and target frameworks or channels through an arrangement of framework APIs. For instance, in a buy arrange process, there is some rationale that is regular crosswise over items, geologies and retail channels that can and ought to be refined into a solitary administration that would then be able to be called.
And you will get some more clarity from this article https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how
System API and Process API will be part of API led connectivity.
System API is like awrapper service to either a main data base or saas platform
Process API involves application logic to validate search or query parameters
At first brush, OData seems like it will only appeal to "open" databases, and would never be used in envrionments where security is needed, especially with financial or government clients.
Is this the correct perspective to have with the current version of OData/WCF? If not, can you share whatever I would need to change that perspective?
Update
Examples of current concerns include:
Increased possibility of SQL Injection
Additional Data Validation (complicating business logic)
Unauthorized Access to data
Increased ability to do a "raw dump" of data
by this I mean it is easier to use OData to get to HR data, then it is to screen-scrape a traditional ASP.net page
Update 2
Is it also possible for me to enforce business rules? For example a properly formatted SSN, Phone, or Zip. How about ensuring all fields are filled in?
oData is just a way to expose structured data through an open API. It does not requre any particular form of security; it's possible to have fully open datasets (like a wiki database) or world-readable-but-private-writeable (such as a database of votes by members of Congress, so anyone can read it but only you can update it). It also supports more complex security structures (such as a video rental store allowing customers to query only their own history).
Regarding your specific concerns:
SQL injection is simply not possible if you're using the ADO.NET Data Services as your oData server. The incoming oData request is parsed and then passed to an IQueryable, which properly escapes all values.
The business layer / data layer validation remains the same. oData just provides an API for the data layer (or business layer, if it looks databaseish).
Unauthorized access to data isn't possible unless you allow it. The default for ADO.NET Data Services is to not allow any access (even read-only access), so that forces you to explicitly authorize all access.
The "raw dump" scenario is exactly why oData is so useful! It's a protocol that allows efficient querying of data sources over the web, instead of depending on fragile screen scraping "solutions". If you don't want someone to get the information, don't publish it.
Right now (to my knowledge), ADO.NET Data Services is the only oData provider available, and it's secure by default. I suppose that someone else could write an oData provider that wasn't secure by default or allowed SQL injection, but that would be foolish.
Also, remember that oData is completely divorced from the concept of authentication. It's up to you to use whatever authentication makes sense for your API. There's a great recent series of blog posts from the WCF team that address how oData works with various forms of authentication.
What's your business case for using OData? OData primarily exists to expose your data in a platform agnostic manner... so that .NET, Java, Php, Python, REST, etc clients can all access your data. Is that your use-case?
Or are you trying to expose your data via a service layer (kind of an SOA approach) so that your clients (which you control) are better decoupled from your data sources. In that case, OData may not be the right solution. I looked at OData as part of a data service layer and decided it is too slow. I'm now looking at Devforce which implements service-based access for Entity Framework models (via their BOS service)... full CRUD operations including LINQ to service-hosted model.
Security is to you desired level is possible either view OData or via DevForce. Pick the correct data-remoting solution, then research the correct security implementation.
Sure you can use it in government solution. OData is just a way of accessing data, it has nothing to do with making the information secure. You have to implement the security at the transport level (SSL) and not at the application level (provide login and password to application).
There are many ways to go about this. One example is if you are using SSL, you can force your client to provide a client certificate and have that do the authentication. Once the person has authentication, you can use your application to limit what they can see (maybe they can only see their client information, so all queries automatically limit the person to seeing that.)