Single or Multi-Subaccount solutions with one SSL Host to achieve environment isolation

Introduction

With a configured Custom Domain, you can map your SCPI applications to your custom domain names so to replace the Cloud Platform name (usually ”<Region>.hana.ondemand.com”) with some value that reflects your company or your business process. For an overview on this topic, refer to this link.

Purpose

This document aims at showing solutions you can build with a single SSL Host based Custom Domain along with an accurate use of Subaccounts (in particular its related application url, it’ll be explained later on) and Addresses in a SOAP web services scenario.

The isolation level achieved with the configurations described below is based on one SSL Host. The highest isolation level would be achieved with two SSL Host which allows you to completely separate test and production environments but this is not discussed here. This document is for whom has only one SSL Host and wants to make the best use of it.

The main questions to answer might be the following:

• If I have only one subaccount, how can I create isolated test and production applications?
• If I use two subaccounts, what’s the best way to create recognizable test and production environments?
• Can I use different addresses to isolate iFlows for test and production purpose?

By reading this document, one should get a wider range of options to better evaluate different scenarios and decide accordingly.

Prerequisites

The prerequisites are:

• Knowing the difference between Global Account and Subaccount, for details have a look at the Jakob Moellers’ blog Understanding SAP CP Global Accounts
• Basic concepts lying behind SSL Host and Custom Domain in SCPI; knowledge of SCPI developments is preferable
• An SSL Host created on your SCPI Global Account
• SAP neo-java-web-sdk installed on your local machine

Assumptions

I assume the following:

• At least one quota available for Global Account, therefore one SSL Host configured (I use one SSL Host with bound domain certificate but the certificate is not mandatory for the purpose of this demo)
• DNS correctly configured for Custom Domains we’re adding. Before preparing this demo, I’ve added 2 CNAME records to be used as test and production Custom Domains

Before starting

Let’s get familiar with the elements we’re going to work with:

• Custom Domain: is a domain created in a SCPI Global account and it could be associated to different subaccounts. It’s not the SSL Host; the SSL Host can contain more than one Custom Domain to be mapped to different application url (different subaccounts)
• Global Account and Subaccounts: generally speaking, the Global Account is a sort of container for subaccounts, the subaccount holds iFlows
• Address: this is the parameter specified in the Connection Details of your iFlow, for example this is configurable as part of a sender SOAP channel

The schema above represents a generic scenario with 2 Subaccounts, 2 different Addresses and 2 different Custom Domains.

The iFlow I’m using in this demo is a “GetTime” SOAP Synchcronous WS that returns three parameters: (1) the application name (it’ll be different for test and production subaccounts), (2) the use for that iFlow (TEST or PROD, the fact it’s a specified returning value will be clear soon) and (3) the time value.

This document shows examples based on Console Client Commands. In particular, the add-custom-domain command is frequently used. Let’s pay attention to one of its parameters: –application-url. This is made up by:

https://<application_name><provider_subaccount>-<consumer_subaccount>.<domain>

Let’s quickly explain it:

• <application_name>: find it in Global Account -> Subaccount -> Applications -> Subscriptions -> under column Applications of “Subscribed Java Applications” page (it’s the working node, the “cxxxxxxiflmap” string)
• <provider_subaccount> : find it in Global Account -> Subaccount -> Applications -> Subscriptions -> under column Provider Subaccount of “Subscribed Java Applications” page
• <consumer_subaccount> : find it in Global Account -> Subaccount -> scroll down up to the “Subaccount Information” frame
• <domain> : usually the string “<Region>.hana.ondemand.com”, verify it from your Global Account Overview section

NOTE: technical data in this document as subaccount name, domain name and so on, are not hidden (but the company domain name which is displayed as “mycomp<XXX>”) to make such information easier to compare with your configurations.

NOTE: in this document, the application-url parameter always starts with “https://“, this can be omitted! It works anyway.

1 Subaccount scenario

You have only one subaccount (the production one) and you want to have your test and production applications separated and reachable at different points.

Suggestion 1: use different addresses

Copy the package containing the iFlow, add a recognizable suffix (for example TEST) and assign two different addresses to the sender SOAP channels. Deploy the 2 iFlows with different addresses indicated in the sender SOAP channels.

How it is configured

Map the custom domain to the production application url.

neo add-custom-domain --account ac00xx123 --user S00xxxxx261 --host hana.ondemand.com
--custom-domain prod.mycustomdomain.mycomp<XXX>.com --application-url https://l009999iflmapavrhcip-ac00xx123.hana.ondemand.com --ssl-host MyCompanySSLHostname

The resulting mapping.

The resulting endpoints.

Production

Test

Test the applications.

Production

Test

When you have 1 subaccount, indicating “prod” or “test” in the address is useful to distinguish iFlows developed from scratch (custom iFlows). Whereas if you’re working with standard solutions, it could be better not to change the production address and working only on the duplicated-for-test package. In this case we would have:

https://prod.mycustomdomain.mycompXXX.com/cxf/test/standardServiceName

https://prod.mycustomdomain.mycompXXX.com/cxf/standardServiceName

NOTE: before doing a TEST copy the the standard package, always check if all the elements are paramiterizable. Sometimes you can change the endpoin to call the iFlow but you could have troubles calling Process Direct elements or data store (because of the existing name deployed with the original pacjage). Do a thorough check before following this approach.

Suggestion 2: use different addresses and use different Custom Domains too

This solution works exactly like the previous one. In addition two different Custom Domains have been set pointing to the same application url. Actually, this is useless from an isolation point of view since we’ve already achieved it by differentiating the addresses. Let’s suppose that for some reason raised by your application consumer (3^rd party application) you’re asked to provide WSs reachable at different domains, we can achieve this anyway.

How it is configured

The first custom domain has already been added (see “1 Subaccount scenario- Suggestion 1” of this document). Add the second Custom Domain (the test one).

neo add-custom-domain --account ac00xx123 --user S00xxxxx261 --host hana.ondemand.com --custom-domain test.mycustomdomain.mycomp<XXX>.com --application-url https://l009999iflmapavrhcip-ac00xx123.hana.ondemand.com --ssl-host MyCompanySSLHostname

Now there are 2 Custom Domains mapped to the same application url.

The resulting endpoints are 3 for each iFlow (1 default and 2 custom).

Production

Test

NOTE: now both “/cxf/test/getTime” and “/cxf/prod/getTime” are reachable from any of two Custom Domains! For this reason, there should be some parameter or some kind of logic into your iFlow that stops the data processing if information comes from the wrong address (something like “IF 3^rd Party application called the TEST Custom Domain at PROD Address, stop the process).

This kind of solution is unsafe because it’s leads to confusion. Let’s just show that it works for demonstration purpose.

Production

Test

Dirty case: production address is called at the test Custom Domain (there’s no control implemented at iFlow level on who is calling what)

If you call a test Custom Domain based application, you don’t expect to get the response from a production application. This is a big downside of this solution.

Multiple Subaccounts scenario

You dispose of more than one subaccount (2 in this demo): one for test and one production. You want environments to be isolated and reachable at different points.

Suggestion 1: use different Custom Domains

Map 2 Custom Domains to 2 application url which are different for test and production subaccounts. The addresses for test and production iFlows are equals since there’s no need to differentiate them because the applications run on different server nodes.

How it is configured

Add the production Custom Domain.

neo add-custom-domain --account ac00xx123 --user S00xxxxx261 --host hana.ondemand.com --custom-domain prod.mycustomdomain.mycomp<XXX>.com --application-url https://l009999iflmapavrhcip-ac00xx123.hana.ondemand.com --ssl-host MyCompanySSLHostname

Add the test Custom Domain. Please notice this time the –account parameter changed: it’s the test one and it must be the same of the one indicated in the application url. The application name changed too (it’s the one starting by “e“).

neo add-custom-domain --account wy00xl123 --user S00xxxxx261 --host hana.ondemand.com --custom-domain test.mycustomdomain.mycomp<XXX>.com --application-url https://e008888iflmapavrhcip-wy00xl123.hana.ondemand.com --ssl-host MyCompanySSLHostname

Here the result.

NOTE: I run the list-custom-domain-mappings command indicating the production subaccount ac00xx123 and I get result both for production and for test subaccounts. This because the mapping is hold by the SSL Host which is a Global account object (the visibility is therefore global).

Each subaccount has different endpoints.

Production

Test

Let’s test them both.

Production

Test

Suggestion 2: use different Custom Domains and use different addresses too

This is a mix of the “1 Subaccount scenario – Suggestion 1” and the “Multiple Subaccounts scenario – Suggestion 1” of this document. It looks redundant since the two iFlows are already isolated being in different subaccounts. Indicating the purpose (prod or test) in the address too could lead to confusion.. or it could be done for scalability reason. The choice is yours!

Anyway, the steps to achieve this can be taken from the above solutions, so I’m not going to show it.

Conclusion

Keeping test and production environments isolated is important even when applications developed by others are conceived to run for test and production purpose in the same environment. If it’s not possible to dispose of separated environments, the isolation should be achieved differently.

Thanks for reading.