Connect Sap Analytics Cloud (SAC) to Marketing Cloud (SMC) - Live (two ways vs one way) vs Import

[JaySchwendemann]

Dear all,

we have a requirement to build analytical scenarios in SAC based on data from SMC. Roughly we have two possible routes, where I only find documentation for the first one

1. Live Connection
2. Import Connection

I tried to go the Live Connection route first, albeit it is not needed to have an application kind of integration in SMC where one could browse / see SAC stories in SMC (if that is what distinguishes application enabling integrations from "normal" ones, see below)

So within the Live Connection we seem to have again two possibilities

1. Application Enabling Integrations "Integration with SAP Analytics Cloud (1SO)" (two way)
2. "Normal" Live connections (one way)

With every possibilitiy I have some questions / uncertaincies, unfortunately

1. Live Connection Application Enabling: Do you really need to bind your SAC to the SMCs slices of IAS for SAML IdP authentication? In other words: even if we preface that SAML authentication with a corporate IdP, technically we are connected to SMC-IAS and when SMC will be phasing out we will need to reconnect things?
2. Live Connection Application Enabling: In that vicinity, did someone succeed staying with a corporate IdP on the SAC side (one does not have that liberty on the SMC side, I know)
3. Live Connection Normal: In this setup I read the help file that it would not be needed to be on the same SAML IdP. Did someone do this kind of connection successfuly? If so, what would I be missing from the full fledged "Application Enabling" connection? Really just ways of seeing SAC stories in SMC?
4. Import: I did not find any explicit information on Import Connection from SAC to SMC.Would those connection re-use the communication arrangement "SAP_COM_0065" and those INA services in there? Any push in the right direction would be great

I know, this is a mouthful. I'd be happy for any input on this

Many thanks and kind regards

Jens

[isathore]

Hi Jens,

That's a lot of questions ;).

I must admit that I don't understand what you exactly want to know and why.

Let me come back to the basics just to make sure that we are on the same page.

SAP Marketing Cloud offers 2 types of integration with SAP Analytics Cloud, depending of the SMCr license:

- SAP Analytics Cloud, embedded edition

- SAP Analytics Cloud manual integration

This is all explained in our online documentation Setup of SAP Analytics Cloud, Embedded Edition/SAP Analytics Cloud | SAP Help Portal > Identifying Your SAP Analytics Cloud Version.

Now, based on what you wrote, I assume that you are referring to the 2nd one, the manual integration.

If so, we don't have what you call "import" connection. We provide a live connection with an SAP Analytics Cloud tenant to which you have access. There is no "exchange" of data between the 2 system. The live connection means that the data is read from SAP Marketing Cloud and consumed in analytics stories in SAP Analytics Cloud.

So, to your questions:

1. Please 1st check our online documentation about using a corporate IdP User Provisioning (with Corporate Identity Provider) | SAP Help Portal and Pushing Your Users to SAP Analytics Cloud, Embedded Edition/SAP Analytics Cloud | SAP Help Portal > Pushing Users to SAP Analytics Cloud. Obviously, if SMC is no longer used, the integration with SAC is no longer there. I didn't get this part of the question.

2. This is indeed possible, not sure what you are looking for.

3. I don't understand what is a normal live connection and what you mean with an Application Enabling connection.

4. You don't find anything on "import" connection because it doesn't exist. Not sure what you are looking for. There is no transfer of data possible between SMC and SAC.

I hope this helps already until you provided a bit more details on what you are trying to achieve.

Best Regards

Isabelle, Product Owner SAP Marketing Cloud

[JaySchwendemann]

Hi Isabelle,

many (!) thanks for your elaborate answer and sorry, if the initial question was not clearly phrased. I'll try to clarify

Now, based on what you wrote, I assume that you are referring to the 2nd one, the manual integration.

Correct

Please 1st check our online documentation about using a corporate IdP User Provisioning (with Corporate Identity Provider) | SAP Help Portal and Pushing Your Users to SAP Analytics Cloud, Embedded Edition/SAP Analytics Cloud | SAP Help Portal > Pushing Users to SAP Analytics Cloud.

I understand that there is the possibility to have a corporate IdP in front of SAC and SMC, in fact our current setup is to have (Microsoft Azure AD) as corporate IdP in front of both. However, for SMC you are forced to use a (i call it) "slice" of IAS, even if you setup that in proxy mode. When reading the documentation I read "Both applications must use the same SAP Cloud Identity Provider (IdP)." and "In your SAP Cloud Identity Services - Identity Authentication system, open the administration consol..." This will efectively bind my SAC to SMCs IAS IdP.

I want to avoid changing the IdP of SAC to SMC-IAS because of the following reasons

• Different, already established nameID formats for SAC and SMC
• Not willing (if not really needed) to increase complexity for SAC which runs fine with its own IdP to be bound to SMC-IAS just because of one analytical scenario. I could also put it this way: When next year someone would want to have a analytical scenario on SAC with say FieldGlass (I'm making that up) and Fieldglass would also need to force me with SAC to it's same IdP as SMC does, what then? Switch IdP ever so often?
• If we would (need to) switch away from SMC, we than need to touch IdP of SAC also.

 This is indeed possible, not sure what you are looking for.

This might be reason for your confusion in 1. As I said reading the documentation I'm under the impression that we (at least) need to bind SAC under the hood to IAS IdP even if we then proxy to our corporate IdP. If live connection like documented here will work without touching our current SAC IdP setup (directly bound to Azure AD), then this would be great

 I don't understand what is a normal live connection and what you mean with an Application Enabling connection.

Yeah, that was me in a hurry resulting in fuzzy wording. With "normal" I mean a live connection where I don't seem to need a outbound connection from SMC to SAC. Just a live connection to an S/4HANA Cloud system (that happens to be a SMC) like so

With "Application Enabling connection" took the wording of your documentation 😉 (and maybe missused it in my context). This seems to be the "off the shelf" integration of SAC and SMC but I really don't need any fancy options to see SAC stories in SMC if that would force me into harmonising the IdP.

 You don't find anything on "import" connection because it doesn't exist. Not sure what you are looking for. There is no transfer of data possible between SMC and SAC

Ok, that's a shame. I was looking for something similar e.g. to this where Cloud Integration is used as a data source for a (what I think is a import) scenario. For what I see SAC there is using a import connection to an OData service in Cloud Integration and one could schedule refrehs of the model in SAC. Maybe I was a bit naive in assuming something similar could be done leveraging the existing communication arrangement SAP_COM_0065 or other means to get the data from SMC into SAC

Basically I want to achieve a near standard solution (I learned that being the live connection described here) but without the hassle of meddling with the IdP setup (especially on SAC).

Many many thanks again and sorry for the even lengthier explanation of the initial post 😉

Have a good one

Cheers Jens

[Matthew_Shaw]

Hello Jens

Good idea to tag me on this.

/////////////////

Am I assuming correctly, that it is vitaly necessary to have the same NameId between SAC and SMC configured and have them both federated with the same IdP (for us this is MS Azure AD)

There is no need for the IdP to issue the same Subject NameID for both SAC and SMC, though it's helpful if it does just from a pure consistency point of view, but there's no technical reason they need to be the same at all. Indeed many IdPs will issue a different Subject Name ID for each application. So if the IdP issues abcde for SAC and 12345 for the same user using SMC then that's just fine.

/////////////////

Overall, I would recommend the use of USERID to map the user to the IdP as this way the SAP Analytics Cloud user id will be what you want it to be. It will be the same as the Subject Name ID, though there are limitations to what the USERID can be for SAP Analytics Cloud. (Unpermitted Characters in User Names) Some of these limitations include, for example, the use of a dash (-). You're not allowed a dash (-), but you are allowed an underscore (_). An IdP can dynamically change the Subject NameID to conform to what is permitted and replace a dash (-) with an underscore (_) for example. If this can be done, then it would be better than using the 'CUSTOM' option in my opinion. Manipulating the NameID when using SAP Identity Authentication, Microsoft Azure, Microsoft ADFS, Okta

/////////////////

Benefits of a predictable USERID of your choice (when using USERID to map the user attribute to the IdP from SAP Analytics Cloud SAML SSO)

• Users make sense of the SAC USERID
• it appears within the user interface

Easier to control

• row level security is based on SAC USERID

Gain insights easier

• Activities log identifies the user by SAC USERID

Resolves sharing permissions when content moves about the landscape

• Some artifacts store within themselves who can access it by SAC USERID

When changing the SAML SSO setup in SAP Analytics Cloud there is a difference between the Enterprise and the Embedded Edition. For the regular Enterprise edition, you must change the SAML SSO authentication method back to default before changing it back to use a different user attribute to map to. For example, if its currently set to use email, then you must change it back to the default before then setting up SAML SSO again to map on USERID. This is unlike the Embedded Edition where my blog explains the difference and provides a sample script to do all the API work for you!

/////////////////

If we need to have the same NameID content I assume we will need to switch SACs User Attribute from currently User ID to then Custom SAML... When doing so, would we expose us the risk of locking the system owner out? Ideally it stays authenticated through its cookie, right?

You can always reset the SAML SSO setup via the Identity Provider Administration Tool, so you can always self-serve should you find the System Owner can't access the service for some reason (once you 'reset' the SAML SSO to the default, just press the password reset button to get a new password as you may have forgotten it when using the default setting)

/////////////////

So I suspect you may not need to change the SAML SSO user attribute mapping, but can I just comment on the plan, because its good, but not quite right:

1. Export all Users from SAC

2. Change the SAML_USER_MAPPING to the same IDs we have in SMC for all users, leaving the User ID as is so UserID still is "abcde" but SAML_USER_MAPPING is "12345"

3. Import the CSV again into SAC

4. Change the user attribute from User ID to Custom SAML User Mapping in SAC

5. Change the Azure AD SAML Config to send "12345" in NameID to SAC

Step 5 must be performed before step 3 because any custom SAML user mapping value will be ignored unless the SAML user attribute mapping is already set to custom. For the Enterprise edition, you must also set the SAML SSO back to default before changing it to something else. For both Enterprise and Embedded, you can use the SCIM API to change the SAML user mapping values for you (again after step 5) and my sample scripts mean you can use them without having to write any code. Sample 409, 419 and 429 can do this - also see my blog for some examples, search for SAML Mapping) As I mentioned, better to use USERID over email and better to use USERID over custom for the reasons I've mentioned above.

/////////////////

Do you know about that ominous restricution "Custom SAML User Mapping with the SAML assertion based on Login name is the only out of the box supported configuration for this step. Support for other configurations is not guaranteed." from here. does this hinder us?

I don't know, but I don't believe it will. Check the unsupported characters list, but I suspect the same datatype has been used for both, so I doubt there would be a problem, but you never know! 😉

Hope this helps?

All the best, Matthew

[JaySchwendemann]

Thanks a ton, Matthew,

sorry for the delay but at least we have been somewhat busy to clarify some things in our current setup.

So here we go, partly intertwined with your ansers above

----

There is no need for the IdP to issue the same Subject NameID for both SAC and SMC

We could confirm that creating the live connection SAC --> SMC worked when we aligned SAC's USERID with SMC's business user's user name. It did't work when the usernames were different. In the above example I created a fresh user that had "12345" in both systems and created the live connection with that user.

As the Live Connection SAC --> SMC technically seems be using an OAuth2 SAMLBearer authentication I would feel that naturaly Authorization on SMC would work with the then passed "12345" from SAC to SMC where it would fail because no mathing User in SMC was found when SAC sends "abcde". Also "Enable a Custom SAML Identity Provider" kinda tells the same, albeit in the context of an S/4HANA Cloud system (but since SMC is technically an S4H Cloud system, I would think it applies)

Note
If you are using a live connection to SAP S/4HANA Cloud Edition with OAuth 2.0 SAML Bearer Assertion, NameId must be identical to the user name of the business user on your SAP S/4HANA system.

For example, if you want to map an SAP Analytics Cloud user with the user ID SACUSER to your SAP S/4HANA Cloud user with the user name S4HANAUSER, you must select Custom SAML User Mapping and use S4HANAUSER as the Login Credential in Step 10.

If you are using SAP Cloud Identity as your SAML IdP, you can choose Login Name as the NameID attribute for SAP Analytics Cloud, then you can set the login name of your SAP Analytics Cloud user as S4HANAUSER.

If you are using a live connection to SAP S/4HANA Cloud Edition with OAuth 2.0 SAML Bearer Assertion, NameId must be identical to the user name of the business user on your SAP S/4HANA system.

For example, if you want to map an SAP Analytics Cloud user with the user ID SACUSER to your SAP S/4HANA Cloud user with the user name S4HANAUSER, you must select Custom SAML User Mapping and use S4HANAUSER as the Login Credential in Step 10.

If you are using SAP Cloud Identity as your SAML IdP, you can choose Login Name as the NameID attribute for SAP Analytics Cloud, then you can set the login name of your SAP Analytics Cloud user as S4HANAUSER.

However, I could be wrong, of course 🙂

----

Overall, I would recommend the use of USERID to map the user to the IdP as this way the SAP Analytics Cloud user id will be what you want it to be. It will be the same as the Subject Name ID,

Just to be sure we are on the same page: You are (kind of) advising on changing SAC's USERID from "abcde" to "12345" but leaving user attribute Mapping to USERID? If so, wouldn't that result in new users being created (as there is no real way to change a USERID, as you have outlined before). If yes, we would then need a way to "move" the existing user content (stories, team assignment, ...) from the old user to the new user. Then your Postman collections might come in handy but still seems like some effort and a task well considered beforehand. My guts feeling is I wouldn't want to go that route if not really (really necessary.

Or did I missunderstand and you are merely advising from a SAC POV to have the most consistent way of adressing a user and use that in the USERID? If I did missunderstand, could we then just leave the USERID as is (abcde) and change the SAML user attribute to Custom to then match the one in SMC (12345)? When speaking coherent / consistent adressing the User, we are actually better of with SACs abcde (as that is the windows SAMAccountName of the user hence well known) as we are in SMC where the business users username is a IDM based Id that the users are (not yet) familiar with

----

When changing the SAML SSO setup in SAP Analytics Cloud there is a difference between the Enterprise and the Embedded Edition. For the regular Enterprise edition, you must change the SAML SSO authentication method back to default before changing it back to use a different user attribute to map to

We are on enterprise editition. So if we need to / want to change the user attribute to "Custom SAML User Mapping" we really need to revert back to default IdP (being SAP ID Service) because the input field "user attribe" is read only once set? (I'm not a system owner so I could not check). If so that's partly partly X-D and partly 😮

Assuming one must revert back to the default IdP, this would then leave all users locked out until we did our little 5 step dance (with corrected step sequence), right?

Many thanks again, if you feel coming back albeit a lenghty thread here 🙂 If not thanks anyways for the valuable input ❤️

Cheers

Jens

[JaySchwendemann]

Hi matthew.shaw and of course all

I took the liberty tagging you as you mentioned that in this blog of yours to be fine with you.

That being said, this issue is sadly still not resolved at our side (of course also had a lower priority in between times).

We basically have "abcde" as userID in SAC and "12345" as UserID in SMC.

I have the following still open questions

1. Am I assuming correctly, that it is vitaly necessary to have the same NameId between SAC and SMC configured and have them both federated with the same IdP (for us this is MS Azure AD)
2. If we need to have the same NameID content I assume we will need to switch SACs User Attribute from currently User ID to then Custom SAML... When doing so, would we expose us the risk of locking the system owner out? Ideally it stays authenticated through its cookie, right? And in case things go south, we still have https://me.sap.com/notes/2908073, right?
3. Are we under the risk when changing the user attribute on SAC side to Custom SAML... that the current users in any way get affected in such that they loose connections to their created content? That would be worst case scenario for us. Mind we plan to make the switch like so
   1. Export all Users from SAC
   2. Change the SAML_USER_MAPPING to the same IDs we have in SMC for all users, leaving the User ID as is so UserID still is "abcde" but SAML_USER_MAPPING is "12345"
   3. Import the CSV again into SAC
   4. Change the user attribute from User ID to Custom SAML User Mapping in SAC
   5. Change the Azure AD SAML Config to send "12345" in NameID to SAC
4. Do you know about that ominous restricution "Custom SAML User Mapping with the SAML assertion based on Login name is the only out of the box supported configuration for this step. Support for other configurations is not guaranteed." from here. does this hinder us?

Many thanks to you Matthew and all

Cheers

Jens

[isathore]

Hi Jens,

Sorry for the delay, I was checking with other colleagues. A few things to wrap this post:

• The recommendation is to use one IdP. If you want to discuss details, we recommend to post in this community SAP Cloud Identity Services | SAP Community. We are not expert on IdP and it would be best to contact those experts. You might even need to engage with SAP consultants in this area.
• As discussed, there is no such data exchange between SMC and SAC. It is possible to use the CDS extraction mechanism to bring data to BW, for example, and then use BW as a data source to SAC. See details in our online documentation Core Data Services-Based Extraction from SAP Marketing Cloud to SAP BW Systems | SAP Help Portal .

Sorry that we cannot provide more guidance. Hopefully, the IdP colleagues from the community SAP Cloud Identity Services | SAP Community can help you.

Best Regards

Isabelle