Job interval impact for transport creation, release and import from SAP Cloud ALM

[SAPSupport]

Hi, 

according to this page:https://help.sap.com/docs/cloud-alm/setup-administration/setting-up-managed-systems?locale=en-US

The data transfer between on-premise SAP system to SAP Cloud ALM, is always the direction that on-premise system PUSH data to Cloud ALM.

Does it mean that, if I follow the default collection interval as defined in /n/SDF/ALM_SETUP, then I need to wait the corresponding minutes for the transports to be created / released / imported in the backend on premise system, after I perform the action in Cloud ALM?

For example, when I create a transport in SAP Cloud ALM, then I need to wait maximum 10 minutes, before the transport can be created in backend on-premise system?

if yes, what's the risk, if I shorten the interval to 1 minute?

I mean, currently in SAP Solution Manager ChaRM (Change and Request Management), it's a syncronous process. When I trigger transport creation in ChaRM, it's created at the same time in the backend SAP system, and I know from ChaRM immediately if the creation is successfully or not.
When it comes to SAP Cloud ALM, if this is an asyncronous process, it's very user unfriendly. Firstly I need to wait up to 10 minutes for the transport to be created, and then another 10 minutes for the status to be reflected in Cloud ALM.

------------------------------------------------------------------------------------------------------------------------------------------------
Learn more about the SAP Support user and program here.

[SAPSupport · Accepted solution]

Yes, the interval of the job for Implementation features has a direct impact on the time it takes to create, release, and import Transport Requests. The default values are set with high numbers, but can be changed to lower numbers if desired. 

The SAP Help Portal documentation for SAP Cloud ALM outlines the following in section Configuring the PUSH Data Provider (just above section Configuration of the Transport Organizer Web UI😞
Note
For your test or productive landscape, set the collection interval to 1 min for these use cases if you want a quicker reaction to your testing of creating transport request, transport of copies, and triggering the deploy in the features. 

SAP Cloud ALM is not an on-premise system, and as such it does not use the same technology to communicate with the on-premise systems. It must use asynchronous communication to trigger actions and receive updates from on-premise systems. 

Reducing the job interval time carries the same risks as scheduling any periodic job at very short intervals. If the jobs have to trigger a lot of tasks or transmit a lot of data back to SAP Cloud ALM, this can consume on-premise system resources and impact performance. If this happens, the configuration can be altered to increase the interval value at small increments (1 minute at a time) to find a balance between on-premise system performance and SAP Cloud ALM update wait times. If the on-premise performance impact is severe and seems like an issue, a Case should be created to investigate in case an issue or bug is involved. 

[DY_AO · Accepted solution]

Thanks for sharing.

But I would say that compared wih ChaRM, such design in Cloud ALM leads to lowering of user experience. It's definitely a major concern of adopting Cloud ALM for change management. 

Wouldn't it be better to allow Cloud ALM to push transport management actions to the satalite systems?

Name several cases, just like how Ariba syncs PR/PO data to backend SAP, and how SuccessFactors syncs employee data to backend HCM, and SAP Analytics Cloud loads data from backend BW, etc.. all the above mentioned cases work very well via the Cloud Connector tunnel. 

If the transport management actions on Cloud ALM can be passed to satalite systems immediately via the Cloud Connector tunnel, that would be huge improvement.

Note: I am NOT asking for sending on-premise system data to Cloud ALM via the CC tunnel, but the other way around.