Teaching how to use Developer Cloud Service to promote ICS Integrations into new Environments

Why not to have the best of the two worlds? That is, a simple web UI that allows you to easily integrate your SaaS and On-Premise applications, as well as a mature DevOps tooling, that allows you to store your integrations in a corporate version control repository and fully automate your deployments, continuous integration and continuous delivery of your integration projects.

Well, in this blog I am going to show you how simple it is to use Developer Cloud Service to manage your ICS Integrations in a DevOps fashion.

That is:

  1. DevOps person pushes a change in an ICS Integration into the corporate Git repository,
  2. A build task is triggered based on a Git code change being detected. Hudson will automatically trigger a build task,
  3. Hudson will build and package the ICS Integration and archive the result as a release for future deployment,
  4. A deployment task is triggered to deploy the ICS Integration into a configurable target ICS environment.
  5. Optionally, we could run tests and report status, to ensure the new code release is functional as expected.

This blog assumes current knowledge on how to interact with ICS system APIs. If you need more information refer to this other article that I wrote some time ago, that focuses on the ICS system REST APIs that make it possible to interact with ICS remotely.


usermod -aG sudo [USERNAME]

sudo http_proxy= apt-get update

sudo http_proxy= apt-get install default-jre -y

sudo http_proxy= apt-get install default-jdk -y

java -version // Validate Java exists now…

Exporting and Importing ICS Integration into DevCS Git repo

There are multiple ways you can export a given ICS Integration:

If you want to understand how to work with git branches, I recommend this other blog that Ali Mukadam wrote.

git clone https://user@devcsURL/GIT_REPO_NAME.git


git clone

Enter the password when prompted.

This will download the current project within a new folder.

Let’s build our ICS Integration Environment Properties File

As part of the DevCS Build job, we need to call a few ICS system APIs. An easy way to so it is by using Shell Steps in Hudson within DevCS.

It’s up to us how generic we make these shell commands. I like the idea of making it in a way that:

For now, let’s move into a properties file all the configurations that we are going to need as part of the ICS Integration deployment via the ICS system REST APIs

Note: If you need a refresh on the ICS system REST APIs that we are going to be using, read this this blog, as indicated earlier.

For this particular ICS Integration that I am building, I am integrating into Sales Cloud and exposing simple to consume REST APIs, thus I need to configure as part of the Integration a Sales Cloud Connector and a REST Connector.

The way you decide to parametrise your ICS system REST APIs is totally up to you. Below there is an example of how I chose to build my “env” configuration file, use it as a guide to build yours:

NOTE: Depending on your integration, you might have more or less connectors. It’s the DevOps engineer’s responsibility to know what adapters belong to each Integration.

Further things could be parameterized, for example the ICS integration version, ICS server, Datacentre, etc. – This is totally up to your needs.

#    Integration:




#    Connector: Sales Cloud:



#    Connector: REST:



#    Security:



NOTE: Since this configuration file refers to this specific ICS Integration, it make sense to save this file within the integration folder itself (S2VIIA_SC_GETCONTA_INT/)

Let’s configure our ICS Connectors according to my target environment

As part of the DevCS Build job, when we export an ICS Integration, it comes in full including its associated connectors, however, these are not configured. It makes sense if you think about it. You wouldn’t like to export a TEST ICS Integration and promote it to PROD and by mistake forget to re-configure the connectors which are still pointing to a TEST environment… And find that out later on when this is a big issue. Even worse, you wouldn’t like to be creating a TEST environment from a PROD environment and forget to modify the connector configurations and keep pointing to PROD from TEST.

Well, sleep assured that this won’t happen, because the ICS Connectors don’t come fully configured after an export. You need to configure them as part of a re-deployment into another ICS environment.

In a previous blog (see here), I explained that in order to re-configure an ICS Connector to point to a designated environment as part of a re-deployment, you need to send a json file attached to the API Call. You don’t need to send all the configuration parameters, but only those that you want to modify. These could be WSDL locations, username, passwords, etc. However in order to avoid having to build your own JSON documents, which personally I don’t find exciting, a trick that I normally do is to GET the connector’s configuration first and then simply add the modifications. That way we can be sure that the format is right and even better, this way we can version control the environment connector’s configuration.

That said, GET all your Connectors’ JSON files, configure them (if needed) and store them once again within your ICS integration expanded folder, so that you can Git push them together with the rest of your project.

This is the API that you need to use (see this bog for more information on how to configure the Connector once you GET it):

curl -u username:password -H “Content-Type:application/json” -X GET https://server[:port]

Note: Before proceeding, make sure all your Connectors’ configurations are in the right folder and fully configured, i.e. Based on the nature of the ICS connector, you might need to setup WSDL locations, WS endpoints, usernames, passwords, etc. For example, for my ICS Integration I don’t need to do anything for my REST Connector JSON file. However, for my Sales Cloud Connector, I need to setup the targetWSDLURL, eventCatalogURL and Sales Cloud credentials:

NOTE: Once again, it’s the DevOps engineer’s responsibility to configure these connectors properly and for each specific ICS target deployment environment.

Once the fully configured your ICS connector based on the target environment, place your JSON files within the ICS project. A good place to locate it is together with the env-[DEV|TEST|PROD] file and the main icspackage filder..

Let’s Git push our ICS Integration to DevCS

git add -A


git commit -m “Adding S2VIIA_SC_GETCONTA_INT ICS project”

If you get a legend that says: *** Please tell me who you are. Followed by: fatal: unable to auto-detect email address (got ‘cciturria@middlewarepc1.(none)’)


git config “”

git config “Your Name”

For example:

git config “”

git config “Carlos Rodriguez Iturria”

And then, repeat your commit command:

git commit -m “Adding S2VIIA_SC_GETCONTA_INT ICS project”

    Enter the password when prompted.

Let’s configure DevCS to trigger a Build job

Follow the next few steps to configure your build and deployment jobs:

This is a script that I put together, have a look and take the bits that work for you:

# 1. We are going to set our environmental properties, by sourcing the env-[DEV|TEST|PROD] file that you wish to use.


chmod 755 env-${ICS_INTEGRATION_ENV}

source ./env-${ICS_INTEGRATION_ENV}

# 2. Package the ICS Integration “package” as an IAR integration archive – We are going to use jar for this.

jar cvf ${ICS_INTEGRATION_IAR_FILENAME} icspackage

# 3. Import the ICS Integration archive (IAR)

curl -u “${ICS_USERNAME}:${ICS_PASSWD}” -H “Accept: application/json” -X POST -F “file=@${ICS_INTEGRATION_IAR_FILENAME};type=application/octet-stream” ${ICS_INTEGRATION_POST_IMPORT_URI} -v

# Sleep 5 seconds to give time to complete before configuring the adapters.

sleep 5

# 4. Configure and activate my ICS Connectors:

#     4.1 Sales Cloud Connector

# Configure Sales Cloud Connector:

curl -u “${ICS_USERNAME}:${ICS_PASSWD}” -H “Content-Type:application/json” -X PUT -d @${ICS_CONNECTOR_SC_CONFIG_NAME} ${ICS_CONNECTOR_SC_URI} -v

# Sleep 5 seconds to give time to complete before configuring the next adapter.

sleep 5

#    4.2 REST Connector

# Configure REST Connector, in this case I just want to force Test it, so it gets activated:

curl -u “${ICS_USERNAME}:${ICS_PASSWD}” -H “Content-Type:application/json” -X PUT -d @${ICS_CONNECTOR_REST_CONFIG_NAME} ${ICS_CONNECTOR_REST_URI} -v

# Sleep 5 seconds to give time to complete before Activating the ICS Integration.

sleep 5

# 5. Activate the Integration

curl -u “${ICS_USERNAME}:${ICS_PASSWD}” -H “Accept: application/json” -X POST ${ICS_INTEGRATION_POST_ACTIVATE_URI} -v

    Having said that, you can always re-set any of the parameters at runtime. For example, pointing to a different environment by re-setting the parameter ICS_INTEGRATION_ENV to DEV.


You just learned how to fully automate the deployment of ICS Integrations using tools like Git and Hudson within Developer Cloud Service.

I hope you found this article useful. If you have any question or comment, do not hesitate to contact any of the authors of – We are here to help you!

Thanks for your time.