Technical System (Third Party) - Update Hostname

[JaySchwendemann]

Hi all,

I'm integrating a legacy CRM system with our SAP system. Flow should be ERP -> PI -> CRM for transfering customers to CRM.

As the CRM system is a 3 tier (DEV / QAS / PRD) system landscape within our own company domain, I would have opted to create a third party technical system for each, like TS_CRM_D, TS_CRM_Q and TS_CRM_P. When doing this the system calls for a host name. This is perfectly fine now, I know the host name and can enter it as of now. Let's say the host name for TS_CRM_D is crmdev.example.com.

However, I already know, that the hostname of the CRM system will change in the near future, let's say to newcrmdev.example.com.

Question: How would I cope with such situations? Changing of the referenced host name is not possible within technical system section of SLD. I know about associations and that I could edit those, but I'm a little afraid of doing such things that may go havoc as we'll be working "under the hood" then.

Many thanks and kind regards

Jens

[Harish · Accepted solution]

Hi Jens,

AFAIK - In third party technical system the host name can be anything. It would not affect the message flow. Please check the below wiki (specially the reply from

Srinivas Vanamala)

Working with System Landscape Directory (SLD) - Process Integration - SCN Wiki

[JaySchwendemann]

Since it seems that it's not necessary and may be a hassle to have the hostname of a technical system up to date I'm marking Harish's answer the correct one as he was the first one to state the same.

I'm not really pleased that there seems no (easy & safe) way of changing the hostname, especially since it doesn't seem to be used but there you go

Thanks all

Cheers

Jens

[JaySchwendemann]

Hi all,

thanks for pointing out that specifying an arbitrary hostname would work as well as an outdated hostname would do no harm to the actual flow.

However, call me anal on this but I'd really like to always have the correct host name for the technical system in SLD.

Is there any best practice on how to change the hostname for a TS? What would I need to bear in mind?

Thx

Jens

[Former Member]

Hi Jens,

There is no harm if you don't at all update the 'hostname' in the TS of an 3rd party system.

But still if you want to change it, delete the existing TS. Create the new TS with the same name, same details and with updated 'hostname'. Then do a CPA Cache refresh with full mode.

This will keep all the existing things in place. But this activity has to be done in the Business Down-time so as to avoid the data loss.

This will be enough I think.

Regards,

Amit Patil

[Former Member]

Hi Jens,

For creating an Technical System for a Third Party System (in your case legacy CRM System) in SLD, it asks for 'hostname' as a mandatory thing. But there is no harm/impact if you pass anything in the 'hostname'.

Hence if 'hostname' or any technical detail if changes in future, it won't create any problems. So that won't affect your design/configuration of the systems as well as your process flow.

Regards,

Amit Patil

[markangelo_dihiansan]

Hi Jens,

You could always add the new host name as an application server in the technical system. If there would be business systems that would be affected, go to the business system and then in the integration tab change the technical system. Manual synchronizing is still needed if a business system has been imported in ID prior to the host name change.

Regards,

Mark

[JaySchwendemann]

Hi Mark,

how would you add the new host as an application server in the technical system? If I'm in SLD having technical system TS_CRM_D open there's no option fo adding or changing something like an application server

Could you please elaborate on where to set this?

Many thanks

Cheers

Jens

[markangelo_dihiansan]

Hi Jens,

I was under the impression that your TS was an SAP technical system. But yet, even if the hostname changed it would do no harm because it will still be the communication channels that will dictate the protocols of message communication.

Regards,

Mark