hops from sql server to mysql to s4 hana - possible?

  • Hi when i think of server hops , i think of how kerberos assists with credentials from server to server thru what i think are called sids so that the last server knows the credentials of the account that initiated a request/query.

    we'll be talking soon about a need to get data from s4 hana sap (in)directly to sql server.   sql server would be the requestor.  right there in the middle is a mysql server from which we already get unified s4 and other erp sales data thru a mysql connector installed on our sql server.   Our partner who owns the mysql server has created unified views over mysql tables hydrated from s4 data and other erps.  We use a linked server to tap into that unified view.

    we face a need to get something more like a once daily, lives for only 24 hrs,  ods dataset from s4.   I mentioned to my peers that it would seem like overkill for a view over a layer of mysql tables for such a dataset.   For the AR app we would use this for, we tap right into the 10 or so (and growing) erp's whose AR snapshot we are interested in once daily.   Having 2 layers for s4 seems silly and would introduce additional complexity like "when did mysql refresh?",  "where do we look for problems?" etc.

    we'll start talking about options.   one is cdata's s4 connector on our sql server bypassing mysql.   Another may be just installing what is probably the same connector they have on mysql (maybe there is a cost), on our sql server and bypassing mysql.   My head gets a little fuzzy when i think maybe mysql can have views that go directly to s4 which we tap into from sql...or some kind of hop from sql to s4 thru mysql.

    Can the community comment?

     

    • This topic was modified 2 weeks, 6 days ago by stan.
    • This topic was modified 2 weeks, 6 days ago by stan.
    • This topic was modified 2 weeks, 6 days ago by stan.
  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • here is what i think "hops" would look like in this arrangement.   They wouldn't be hops in the traditional sense like ssrs -> sql engine when ssrs and the engine are on different servers:

    ...on our dw sql server thru a linked server, we execute a mysql view, probably with open query.  That view on mysql thru the equivalent of a mysql linked server executes a query against s4 HANA sap, presumably leveraging an s4 connector.   The only down side for me  is that when we need a temporary workaround till something is fixed, we now have to "rig" the query on a different platform, namely mysql.

    I cant see a solution for temporarily "rigging" the s4 query right from our server, without an s4 connector on our dw.   as bad as rigging sounds,  and as infrequently as it occurs, its a reality for us.

    I'm also looking at Fabric 's pipeline technology with  a Fabric sap connector.   Probably a great long term solution but in the short term would probably draw "cons" similar to the "cons" of doing the hops i describe above.

    • This reply was modified 2 weeks, 3 days ago by stan.
  • Maybe this is over-simplifying the problem, but is there any reason why you can't connect directly to the data source?

    In my experience, the more hoops your application has to jump through to get the data (app->SQL Server->MySQL->SAP), the greater the chance for issues and the longer it takes to get the data. Each "hop" adds latency and delays in the data.

    In the event you can't do that, I'd be looking at how close to real-time does the data need to be. If the data can be stale, then I'd use something like SSIS to move the required data from SAP and MySQL to SQL Server and have the app talk directly to SQL Server. Removes all the hops. If the data needs to be realtime or near realtime, I'd look into what options you have at the SAP AND MySQL layer to push data changes to SQL Server IF your app is talking directly to SQL Server. Have the SAP data pulled directly into SQL server and the MySQL data pulled directly into SQL Server.

    Quick google brought me here - https://learn.microsoft.com/en-us/answers/questions/1324505/reliable-data-provider-to-read-sap-data-inside-a-s

    Which says you can install the ADO.NET driver to connect to SAP HANA in SSIS then use SSIS to pull the data out of SAP and into SQL Server. No need for the MySQL server to connect to SAP.

    Basically, the app should talk to the source of the data where possible and if that isn't possible, move the source of the data as close to the app as you can.

    At least that is my opinion on how I'd do it.

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • good question, right now that s4 hana erp is in a different domain.  we just bought that company.  however ssis can run over there .

    i'm not sure if running over there, how ssis could reach back here to insert into our wh.  Or if run over here, how ssis can reach over there to get the data from s4.  we can see/extract from  their mysql catalogs from here thru linked servers .  and i believe from their web apps they can see/insert to our wh server .    so one option they like is using a framework they use in their web apps to read s4 and insert into our wh.   skipping mysql completely.   i'll read that link to see if its just as viable to get the data from s4 via ssis running over here.

  • Is the different domain in the same AD forest? If so, then you should be able to authenticate across and see the other servers and everything should just work. If it is in a different forest, are the machines able to see each other via DNS? If so, you could use local credentials for authentication (SQL Login instead of Windows authentication) and you should be good.

    If you can't see the machines as the DNS isn't set up yet, can you see them by IP? If so, SQL Login should still work.

    If the machines can't see by DNS or IP, then you'll need some middleman thing like the MySQL instance that can see and communicate across both domains.

    One concern I always have with web apps is how they handle failed requests. If you try to use their framework to push data into the S4 or read it out of the S4 and you get a 503 error, what is the correct process to retry? can you just resubmit or do you need to do some extra steps first?

    If their web app can connect directly to your data warehouse, then your data warehouse should be able to interact directly with the S4 without the MySQL middleman, in which case SSIS should be a viable option.

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • the ado.net path looks promising.   My only concern is keeping it updated with whatever changes occur in sap.

    The cdata alternative which is buried further in your links has my interest but i just learned how expensive it is.   We already use cdata for sql to netsuite connectivity which saved us literally over $100K but for this use its justification would be much more difficult.   If sap updates occur , cdata would be all over it.   Cdata seems to have a direct line to vendors like netsuite and maybe sap.  so they could assist in those gray areas where we dont know who to go to for a problem.  Tough call.

    fabric is also intriguing but we just arent there yet.   We are taking baby steps understanding what beside its sap connector is available.

    Anyway, our network guy says they (sap and our sql dw) should both be able to see each other's dns's.     So im going to try to install the sap ado connector on a dev vm and run ssis there.   Will contact the sap admins for anything i need.   Will post back here how it went.

  • i thought i posted what a rabbit hole this looks like but i dont see the post here.   Anyway, AI says the ado connector is downloaded as part of the sap client so i'm going to try that path.    i'll post back here.

  • I like CDATA as a concept, but it is an expensive tool for sure AND it still requires other tools to do the heavy lifting. If you want the ODBC connector for HANA (which I don't know why you'd go with CDATA unless your company is very familiar with them already since SAP provides an ODBC connector already), the cost is $750/year/developer. If you want the whole suite of SSIS connectors, it is a bit more BUT if you use a few of them, the cost makes up for itself pretty quickly - $2500/year/developer. So you can see if you have 3 connectors for CDATA at roughly $750/connector you are coming in at $2250, once you add 1 more, you may as well get the whole suite of SSIS connectors.

    One thing to remember with the SSIS approach though is that you MUST install the connector on your workstation (to develop the SSIS integration) AND on the server hosting SSIS.

    As for the SAP connector, this blog post on SAP covers a good chunk of the setup work:

    https://community.sap.com/t5/technology-blog-posts-by-members/how-to-connect-microsoft-ssis-with-sap-hana/ba-p/13215236

     

    Personally, I've had some bad experience with AI trying to help. Recently, it was telling me to set up SAML for SSO on a system that doesn't support SAML, only OIDC. I've had issues with it giving me bad ACL commands, I've had typos in scripts... It's a good starting point, but I prefer to find the source of truth. Heck, at one point AI was recommending we eat rocks and put glue on pizza... thankfully it has improved a bit since then...

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply