Hi Team,

I need help  where I am doing a POC on SAPUI5 and Netweaver gateway to present .

We have no idea from where to start. Current version is ECC6 with EHP7( 7.4). we want to use the system as Embedded Hub.

I have gone through the below link: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/b054074c-d6cf-2e10-8e96-f818697921fe?QuickLink=index&overridelayout=true&52415781107697

1) Can anyone guide me what are the Pre-requisitions that I need to check and installed in my system.

2) What configurations need to done.

3) SICF   /sap/public/opuis activated, but under   /sap/opu/sdata there is no SDATA node.

Hello,

I created a Entity type and contains parameters then i put one property type as optional and rest of the parameters type as key. So i have ran the Query/URI but i get the error like 'The request URI contains an invalid key predicate'.

Example:

Entity Type : Request

Properties : Name Type : Optional

Properties : Age    Type : is Key

Properties : Place  Type : is Key       

GET Call :

If i call the below URI i get the error mentioned in the above

URI-1: sap/opu/odata/sap/z_sample_test_srv/RequestSet(Name='abc',Age='25',Place='India')?$format=json    ->  Error

If i call the below URI i get respose as successful.

URI-2: sap/opu/odata/sap/z_sample_test_srv/RequestSet(Age='25',Place='India')?$format=json  ->Success

I was wondering if you could confirm which URI is correct ..?

If 1st URI is wrong what is the solution to use optional parameter in URI..?

Thanks,

Suresh

Hello,

I am implementing the SSO with SAML2 for Fiori application. The version of the ABAP server is 7.4.

the connection to the fiori app will be from the inetrnal network so there will be no access from the internet.

I followed the instructions of the following document http://scn.sap.com/docs/DOC-42915 regarding the implementing of SSL, configuration of the windows ADFS and the gateway services in SICF.

when i logon to the fiori App using the following URL :https://<serverName>:<serverport>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/Fiorilaunchpad.html i reach the page of the ADFS

After filling my AD username and password i reach the Fiori logon page.

My username in the AD is the same of the ABAP server, My question is why the mapping of tha BAP user with AD user doean not work so i can login directly to Fiori?

Attached is the debug trace of the "Security Diagnostic tool".

Thanks in advance for your help,

Hassan

I am looking for complete ABAP implementation of the two methods GetEntity and GetEntitySet over SAP table, the implementation should take in consideration filtering, sorting and paging, .etc

Thank you in advance

Hi Expert,

I am able to see this table PA0008 in ECC dev system but unable to view in Gateway system(v-7.40).

Kindly help me sort out this issue.

Regards,

SAM

Hi Expert,

I have doubt,can anyone pls give me ans for this query.

If I have to start custom application in SAP UI5 for travel related .

Backend is SAP ECC.

1. Will I have to developed application on ECC server(WD ABAP)  first and activated it.

  Yes or NO .

2. Based on developed custom travel application on ECC(WD ABAP ) server have to make OData service on SAP gateway server.

Yes or NO .

If "NO" then pls guide me what to do for custom application development in SAP UI5 from SAP Gateway and SAP ECC.

Regards,

Sameer

Looking for the io_tech_request_context-get_osql_where_clause( )  but it does not exist, Am i missing a patch, i am running EHP 7

Thanks

Naieem

Hi All,

We are implementing Fiori, while opening the Track Purchase Order application we are facing a issue.

That CL_SRA020_PO_TRACKING_DPC_EXT=>POLISTS_GET_ENTITYSET() method giving error

This happening while checking for Authorization by standard class.

Regards,

Arun Krishna

Introduction

This series of blogs is an attempt to provide a comprehensive guide to OData and how it is consumed in the SAP world. There has been a lot of content on the Internet explaining what is OData, how the services and published and how to consume which is scattered and assumes that the reader has clarity already on some very important fundamentals. However, there are so many aspects which deserves more than just a mention. In this blog, we will try and cover the topic 360 degrees.

We start with the very basics of HTTP and then gradually build on to OData and finally conclude with a detailed end-to-end exercise on how to create an OData service and how to consume it.

How Internet Works?

It might sound to be an unrelated topic when the focus is on OData. HTTP is the common thread between the two. OData is the underlying protocol on which OData is based and also one of the most common language which is spoken on the Internet.

You would typically need a Web Browser, address of the document you want to read or the URL (Uniform Resource Locator), a Web Server running at the system where the document is located.

Web Browser is a software which is responsible to retrieving and presenting resources on the web. Web Browser parses the HTML response received from the Web and prepares a DOM Tree. DOM stands for Document Object Model and it is a language-independent convention of representing objects in HTML. Web Browser acts as an interface between you and the World Wide Web.

You can request for a document located somewhere on this planet by providing its address via the browser which sends HTTP requests to the web server. The Web server then sends back HTTP response that is parsed by the Web Browser for you to view the document on your machine.

HTTP stands for Hyper Text Transfer Protocol and as the name suggest it defines the semantics of what the browser and the web server can communicate to each other. The how part of the communication or the byte by byte transfer of the data packets across the network is not HTTP but it is done via TCP/IP protocols.

An important component in the story so far is also the Web Server. In a nutshell, Web Server is a server program which sits on a physical server and waits for requests from a client. Whenever a request is received the Web Server prepares a response and sends it back to the client using HTTP protocol. It is important to note that HTTP is not the only but, by far most commonly used protocol and that the client here can be a browser or any other software that communicates in HTTP.

Let us now try and put up a formal definition to the HTTP.

"HTTP is based on a Client-Server architecture style and it uses a stateless request/response protocol to communicate between the client and the web server. The HTTP protocol helps define what requests can be sent across by the client and response sent by web server. The communication of data over the network is however done using on TCP/IP protocol".

It is evident that HTTP is based on client server architecture from our description till now, browser being the client which sends HTTP request and web server which sends the response back to the browser. But, why stateless?

Every single HTTP request that is received by the web server is forgotten after a response has been sent across. Web servers do not process an HTTP request by remembering the previous request. 

URI and URL are not the same thing?

We mentioned a while back that you need to know the URL of the document you wish to view in your browser. Can I not mention a URI as an address to get the document on the web? Let us quickly understand the difference between the two.

URI or the Uniform Resource Identifier can be classified as a name, locator or both that identifies a resource uniquely.

URL (Uniform Resource Locator) is actually a subset of URI that not only identifies a resource uniquely but also provide means of locating the resource.

Defining the Request and Response

HTTP requests are sent with one of the defined Request Method that indicates the action to be taken on the resource. Following are the two most commonly used methods:

GET

This is used to retrieve information of the resource from the server.

POST

This method is used to send data to the server.

For example, if you enter a text string on Google search page and press enter, it will generate an HTTP Request with GET method in the background. On the other hand, if you provide your username/password on a Login page and press enter a POST HTTP request will be send to the server.

HTTP Response from the Web Server comes with data and the status code. The status code provides a context to the response. For instance, if you do not correctly provide the resource location, the web browser will send you a response which you are not expecting. Along with the data response comes the status code, known universally in the HTTP world, that explains to the user what could be the reason for an unexpected response.

HTTP codes are 3 digit integers.

For example, status code 400 means Bad Request. It means that the server did not understand the request.

OData allow creation and consumption of RESTful APIs. In the next blog, I will cover what are RESTful APIs as the next stepping stone towards understanding OData.

Next Blog: OData - Everything that you need to know (Part 2)

In my previous blog, I discussed about how Internet works and gave an introduction to what is HTTP and the difference between URL and URI. IN this blog we will discuss REST based APIs.

Previous Blogs in the series:

OData - Everything that you need to know (Part 1)

What is REST?

REST or REpresentational State Transfer is an architectural style that uses simple and lightweight mechanism for inter-machine communication. It is an alternative to the RPC (Remote Procedure Calls) and Web Services.

REST is resource based unlike RPC or SOAP which are action based. In SOAP you will have a request to get material data whereas in RPC, material will be identified as a resource using URI and then use HTTP verbs to determine which operation shall be performed on the resource. It is important to note here that it is possible to have multiple URIs pointing to the same resource.

Representation of the resource is the not the resource itself but only a representation.

The term representation is how the resources are manipulated in a rest based architecture

Representations depicts parts of the resource state which are transferred between client and server in mostly JSON or XML format. Client will typically have enough information to manipulate the resource on the server.  For example, if Person is modelled as a resource and there is a service to get contact information of a person then the representation that you will get of that Person would be Name, Address and Phone details in JSON or XML format.

The Six Constraints

Following are the six constraints defined which are attributes of a RESTful API.

1. Uniform Interface

Uniform Interface is fundamental to the design of any REST based service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.

What that means is that it should be possible to identify the individual resource in the request, for example using URI. Once the Client has a representation of the Resource then, it should have enough information to update or delete the resource. And that the Client should not assume that any particular action is available on a resource beyond those described in the representation received from the server previously.

2. Stateless

The Server should not contain any Client state. It is possible to process a request only if they are self-descriptive and that the request should have enough context to act upon. For example, if the Person resource address needs to be updated then it is required that the Client pass on the particular Person resource details in the request for which it has received the representation from the Server in the previous request. If the state has to be maintained, it should be at the Client side.

3. Client-Server

We have already established this constraint that the RESTful architecture is a Client-Server architecture. Resource representations are transferred between client and server. We should always keep at the back of our minds that the Client of RESTful APIs will not have direct connects to the Resources.

4. Cacheable

Another constraint on a RESTful API is that any response that is coming from the Sever should be cacheable on the Client side. Caching could be implicit, explicit or negotiable. Implicit and Explicit caching is self-explanatory whereas Negotiable caching means that the Server and Client agree on how long a representation can be cached on the Client.

5. Layered System

The constraint of Layered System is closely related to the above two constraints of Client-Server and Cacheable. It suggests that the Client of a RESTful API should not assume that there will be a direct connection between the client and the server. There could be multiple layers of software or/and hardware in between the two. The Client need not know whom exactly it is talking to and whether a response is coming from the server or is accessed from a local cache. This improves scalability.

6. Code on Demand

This constrains suggests that it should be possible that a Server can extend a Client temporarily. It means that Server can transfer logic to the client as representation to be executed at the client.

This is the only optional constraint.

A RESTful service needs to adhere to all of the above mentioned constraints (except Code on Demand) to be called as a RESTful API.

Having covered HTTP and REST based services we will cover OData in my next blog.

Next Blog: OData - Everything that you need to know (Part 3)

In my previous two blogs, I have covered the basics of how Internet works, HTTP and what are REST based services. So, now that we have laid the foundation we will start with understanding what is OData protocol.

Previous Blogs in the series:

OData - Everything that you need to know (Part 1)

OData - Everything that you need to know (Part 2)

What is OData?

"Open Data Protocol (OData) is an open data access protocol from Microsoft that allows the creation and consumption of query-able and interoperable RESTfulAPIs in a simple and standard way".

The protocol enables the Clients to publish and manipulate the resource identified by URIs and defined in a data model using simple HTTP messages.

To put it in simple words, OData is an open source to exchange data over the Internet. Service hosts the data  and clients can call this service to retrieve the resources and manipulate them. Servers expose one or more endpoints which are services that refers to the resources. Clients need to know this server side endpoints to call the service to query or manipulate the data. The protocol is HTTP based and designed with RESTful mindset which means it follows the constraints to be called as a RESTful service.

Since the protocol is HTTP based, any programming language with HTTP stack can be used to consume OData services. Existing Client side libraries can be used to transform the JSON or ATOM payloads from the server into objects making programming simple. On the other hand, many libraries exists on the Server side to generate the payloads in ATOM or JSON from the existing data.

It is important to note that both Client side and Server side development can be in completely different programming languages till the time both are able to communicate via HTTP.

Clients consume the service to query and manipulate the data from OData Services and are also called as Consumers of OData Service.

Similarly, Servers that expose the OData services via endpoints are known as Producers of Odata services.

So, we now know that in OData protocol, the resources are exposed in two formats; XML based Atom and JSON.

A brief description of what is Atom ad JSON.

Atom is a combination of two protocols, Atom Syndication and Atom Publishing protocol. The Atom Syndication Format is an XML language used for web feeds, while the Atom Publishing Protocol (AtomPub or APP) is a simple HTTP-based protocol for creating and updating web resources.

JSON stands for JavaScript Object Notation is a light weight data-interchange format. JSON is self-descriptive and easy to use and is completely language-independent.

Advantages with OData

There is a lot of data on the web today but lot of it is locked up  in different specific applications or formats and different to access from outside. Many Organizations have now started exposing data using REST based services however, it is difficult to write applications which works with multiple data sources as each provider will  expose the data in a slightly different way. OData service producer can expose its service along with metadata which contains the semantics for consumption. OData exploits the common formats like XML, Atom and JSON for communication which are commonly understood. Clients can now understand these OData services using generic tools and can combine information from multiple data sources.

Exposing your data with OData services comes with multifold advantages. For example, as we mentioned earlier, as a consumer, you need not worry about the programming language used by producer as long as the services are exposed as OData service.

ODBC for the Web

ODBC (Open Database Connectivity) is a standard API to access the database management systems independent of the database management systems or operating systems. ODBC manages this by adding drivers between the Application layer and the DBMS to translate the queries fired by application into instructions which DBMS can understand.

OData has similarity with the ODBC in a sense that here, OData provides the middleware between producers and consumers to communicate data. There is a uniform way to consume data and is independent of the producer much like ODBC. The fact that OData is based on HTTP RESTful services makes it the ODBC for the Web!

In my next blog, I will talk about SAP Netweaver Gateway, SAP OData Channel and the main elements of an OData service.

Next Blog: OData - Everything that you need to know (Part 4)

In my previous three blogs, I have covered the basic concepts of HTTP, what are RESTful APIs and their constraints and finally what are Odata service and that they are RESTful services built that uses simple HTTP to communicate between Client and Server.

Previous Blogs in the series:

OData - Everything that you need to know (Part 1)

OData - Everything that you need to know (Part 2)

OData - Everything that you need to know (Part 3)

OData provides a way to expose the data in a uniform way. Although, Microsoft initially came up with the specification of Odata but, there is a lot of industry support behind OData like, Netflix, eBay, IBM. SAP being one of them. In this blog, we will discuss SAP Netweaver Gateway and how along with OData SAP can cater to multiple channels with a unified data model. In future blogs, we will see how to create OData service in a real-world scenario and explain various aspects of OData during the course.

SAP Netweaver Gateway - An Introduction

For Business Users, ease of access has become critical with the advent of various mobile devices that support end-to-end scenarios and also provides a rich user experience. There is a need to better integrate data, reduce complexity and improve productivity. This has been a challenge for the Developer community to be able to support multiple platforms to consume enterprise data more easily than ever before and on the other hand provide solutions that are scalable and with low TCO (Total Cost of Ownership).

Point-to-point solutions are not the right way as it has lot of drawbacks including duplication of development effort, increased cost, complex landscape, poor scalability and difficult to maintain.

SAP Netweaver Gateway is a technology that has the answer to this. It can seamlessly connect devices, platforms and environments to SAP Enterprise Data using the OData services. SAP Netweaver Gateway offers connectivity to SAP Business data using any programming language and without the need of strong SAP development knowledge.

SAP Netweaver Gateway comes with design-time tools to facilitate modeling OData services for consumption. These tools improve user experience and provide automatic connectivity to the SAP backend that reduces development efforts and improves productivity.

SAP Netweaver Gateway sits on top of the existing SAP Backend infrastructure. There are set of add-on components that needs to be installed on a SAP Backend system to enable SAP Netweaver Gateway services. It is this architecture that enables consumption of SAP data by variety of interfaces such as BAPIs and RFCs

SAP Netweaver Gateway Service Builder tools is SAP GUI based modeler to create and publish Odata services using transaction SEGW.

There is also an Eclipse-based Odata Modeler tool available. It provides an easier way to model the service that is a much easier way to develop if you are not too familiar with ABAP programming language. The models can be conveniently created here are exported to the development environment for the Gateway.

SAP Annotation with Odata

SAP has leveraged the extensibility feature provided by Atom Publishing protocol to add SAP  specific annotations. AtomPub allows you to add your own markups in the service document. SAP adds annotations from the ABAP Data Dictionary, for example, labels to the documents which can then be consumed by the front end application without having to worry about translations in this case.

In my next blog, I will focus on the various deployment options for SAP Netweaver Gateway.

Next Blog: OData - Everything that you need to know (Part 5)

In my previous blog, we introduced you to the SAP Netweaver Gateway and how it leverages the Odata protocol liberates SAP Business Data for consumption on virtually any platform, environment or device.

Previous Blogs in the series:

OData - Everything that you need to know (Part 1)

OData - Everything that you need to know (Part 2)

OData - Everything that you need to know (Part 3)

OData - Everything that you need to know (Part 4)

In this blog we will see the various deployment options for SAP Netweaver Gateway and their pros and cons.

Before getting into the various deployment options with SAP Netweaver Gateway, it is important to understand the different components.

SAP Netweaver Gateway prior to NW 7.4 had three add-ons namely GW_CORE, IN_FND and IW_BEP. While the first two components were required for Gateway server functionalities, IW_BEP was used for Gateway backend functionalities.

From the onset of NW 7.0 release, all the three components are bundle into a single component SAP_GWFND or Gateway Foundation.

There are three possible deployment options to pick from and we will discuss each one of them.

1. Hub Deployment: Development in the Backend system

In this deployment strategy, the SAP Netweaver Gateway is installed on separate SAP machine referred to as Gateway Hub. The OData services are registered and exposed from the Gateway Hub but are developed in the SAP backend system. If SAP Business Suite backend systems are running on NW release prior to 7.4 then component IW_BEP should be installed. For systems running on NW7.4 onwards the SAP_GWFND component contains both Gateway server and backend functionalities as mentioned before.

Advantages of this deployment options are  as follows:

• There is only a single access point of access to the SAP Backed systems. No direct access from outside world provides enhanced security.
• Gateway Hub can be a system running on newer release NW 7.31 or NW 7.4 with Backed system running on lower release is perfectly acceptable.
  • Gateway on newer release would mean support for SAP UI5.
  • Supports added authentication features.
• Direct access to metadata (DDIC) and business data for OData Modeling by backend systems.

2. Hub Deployment: Development in the Hub

Hub Deployment with development in the Gateway Hub is an option where just like the previous option, there is a dedicated Gateway Hub as a separate system from the backend system. Since, all the development related to SAP Netweaver Gateway takes place in the Gateway Hub, backend not necessary should have any Gateway components installed. It is a feasible option if you don’t want to do any kind of developments in the backend system and leverage what is already available.

There are a few disadvantages though:

• Access to the data source for Odata service development is only limited to existing BAPIs and RFCs.
• There will be no direct access to the backed dictionary objects to the Gateway Hub where the Odata services are modeled. The access is limited to only to remote access.
• Having a landscape with dedicated system as Gateway Hub involves additional costs as compared an embedded deployment option. This is true for the above deployment option as well.

3. Embedded Deployment

In the Embedded Deployment option, the SAP Netweaver gateway components are installed as add-ons on the SAP backed system itself. Both the Odata modeling and the exposing of the services is done from the backend system. This deployment strategy saves cost as there is no dedicated Gateway Hub. Also, the runtime overhead due to remote calls in the above two deployment options is reduced.

Disadvantages:

• If there are multiple SAP Business Suite Backed systems in the landscape then, each system will have to have its own installation and configuration of Netweaver Gateway components.
• Upgrade of backed systems will follow a different cycle than that of Netweaver Gateway.
• Additional security measures needed as there is no single access point from the backend system to the consumers.

In the next blog, we will explain the case study that will be the basis of our future blogs related to end-to-end steps of producing and consuming OData services.

Hello Folks,

I am implementing 'Confirm Production Order' transaction application and I am stuck at the following point.

It is a Full Screen application, where initial list of Production Orders is populated by Fiori application via a Odata Batch Operation , which is having following Query { GET AssignedVariants?$skip=0&$top=100&$inlinecount=allpages HTTP/1.1 }. This fails with error message "Resource not found for the segment 'AssignedVariants'".

I checked the Odata implementation in tcode SEGW. There are only 3 entity sets (ScrapReasons,ProductionOperationDetails,ProductionOrderConfirmations). There isn't "AssignedVariants" Entity set which also explains the above error.

In next step when the application calls another batch operation { GET ProductionOrderConfirmations('any_order_number') HTTP/1.1  } , this works perfectly fine and I get the data from my odata service.

In the next step the application calls another batch operation { GET ProductionOrderConfirmations('any_order_number')/GoodsMovementSet } , again it fails because this entity set is not available in odata service implementation.

What can be the possible reason why All Entity Sets called from the Fiori Application are not available in Odata Implementation.

Note : Component versions are as per SAP Fiori Library site  ( ECC is 6.0 EHP 7 , Gateway is Netweaver 7.4 ).

Regards,

Navin

Hi,

I went through the below link

Design Time: How to Compose Multiple OData Services using SAP Gateway

I created two services.

My second service is in the current (same) system.

I created the external association and also generated the run-time objects.

However, I was not able to register using service maintenance feature.

1) How to register using service maintenance? Is it mandatory?

      Because when I click on service maintenance, everything Register and Maintain buttons are graded out.

*************************************************************************************************************************************************************************

When I clicked Call Browser button after activating the main service, I was able to see the dependent service details also in the XML (browser).

2) Can I use $expand in the url to expand the second (dependent) service?

     As I am using multiple service and I don't want to use a single service.

     I want to link this way instead of creating multiple entity sets in the same service.

     Is it possible?

Any suggestions would be helpful

Regards,

Gopa

Hello,

i'm facing a strange behaviour with netweaver gateway.

The application works fine for multiple requests and all of a sudden, the timestamp field contains a blank character.

Can anybody give me a tip, where i could check for the error? The custom code is executed always same.

Thanks for your help.

Kind regards,

Michael

Hi,

I have created a RFC in ECC system. The RFC reads certain values and returns data in three output tables. The corresponding data model has been created in netweaver gateway.

When the portal application is trying to consume this service, it has to specify a particular table in the odata. Thus, to get the data of the three tables, the portal application is hitting the SAP database 3 times.

Could anyone please advise, how can we get the data for all the 3 tables in one go.

Regards,

Jiten

Hi ,

While executing the entity in the gateway client. I'm facing this error which as "RFC Error: The current statement is only defined for character-type data objects".

What should be done for solving this problem?

Thanks and Regards

Itisha Narayan.

In my previous blogs, we discussed the basics of HTTP, REST and finally Odata with context of SAP Netweaver Gateway. We also saw what are the possible deployment options available. In short we have laid the foundation for what is coming in the following blogs, i.e. end-to-end guide of creating, publishing and consuming Odata services.

Previous Blogs in the series:

OData - Everything that you need to know (Part 1)

OData - Everything that you need to know (Part 2)

OData - Everything that you need to know (Part 3)

OData - Everything that you need to know (Part 4)

OData - Everything that you need to know (Part 5)

In this blog, we will define the problem statement and give you a glimpse of what we are trying to build as a small application to showcase the power of OData. We will also build a simple Fiori-like app as a frontend consumer. Knowledge of Fiori is not at all a must here. As I mentioned earlier, during the course of the end-to-end exercise we will also explain various artifacts of OData.

In the next few blogs we will be creating a simple Master-Detail Fiori-like app based on SAP Flight Model example. . We will leverage the existing backend developments to expose the data as OData service that will be consumed by frontend. Future blogs will follow the Embedded deployment environment but, most of the steps we do here is applicable to the other two deployments. It is just a matter of where you do the modeling.

Here, is a link to the Overview of Fiori in case you wish to know more.

The app we are going to develop is a very simple app based on SFLIGHT example to check seat availability and add new flight tours.

Master-detail app will have the left navigation panel will feature the list of Airlines along with codes. The detail section of the app will contain the tabular list of different flights corresponding Airline. User will be allowed to select a flight and check for availability for a given date and class. App will also allow user to add new flights for a specific Airline and dates on which the flights are scheduled. We will showcase the CRUDQ operations along with navigations from master to object view and function imports during the course of this app.

Data Model for SFLIGHT that we will use.

UI Mock-ups for the Sflight App:

Master-Detail view with Airlines information on left navigation panel and various flights operating for a specific airlines on the details section.

Check Availability sceanrio

Information on seats availability

Adding a new Flight tour for future dates.

In my next blog, we will introduce you to the back-end artifacts and start the OData modeling and in the process introduce various concepts.

I don't know much about SAP and I have requirement to access data from SAP and provide Java Web based application to render it and also perform transactions. We are considering Solr for faster search and in order to do that we need to access data from SAP and cache it into Solr documents.

I have no idea how should integrate Solr and SAP? Is it feasible and good Idea to create OData Service or any other thoughts? What should be the best data access pattern for Solr and SAP integration?

Please suggest me some idea and best practices around it. You are more than welcome to share more technical details if somebody may have done this kind of integration.

- Dharmesh