IBM Sterling Ideas

Submit new product ideas for IBM Sterling solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Connect with IBM experts and your peers on the Supply Chain Collaboration Community and the Order Management Interest Group

Enhance C:D Node configuration in B2B Integrator to have Altrernate OUTBOUND Comm Info field

In the C:D Node configuration of B2Bi, we just have the field "Alternate Comm Info" which is used in Inbound connections, and there is no option to specify an alternate IP for the Outbound connections.

This is currently a limitation in B2Bi. This feature is available in Stand alone C:D node but not in B2B Integrator.

Hence in case of B2Bi outbound C:D connections, if the target Primary node is down, the connection will be terminated and B2Bi does not try the alternate IPs.

With this feature " Altrernate OUTBOUND Comm Info" added, fail-over can be managed automatically in case of primary node issues.

Also, in the scenarios where customer is using SFG C:D to route files to internal C:D nodes, setting up an additional Load Balancer can be avoided just to manage the failover from SFG to C:D.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Sep 1 2020
  • Declined
How will this idea be used?

Customer has one flow where the files need to be routed from SFG to an internal Connect:Direct node and there is no Load Balancer.

Two C:D nodes have been configured for resiliency.

However, in Sterling B2B Integrator, there is no option to specify an alternate IP address for outbound connections from B2Bi to C:D.

Hence, when the Primary C:D node goes down, the support team needs to manually update in B2Bi to replace the Primary IP with Secondary C:D IP.

It would be very helpful for the business to have an automated fail-over configuration in case of failures.

It also avoids the introduction of Load Balancer just for this purpose, as we don't require LB for the traffic from C:D to B2Bi.

And many customers who are already using C:D in their solution, expecting this feature in B2Bi as well.

What is your industry? Financial Markets
What is the idea priority? High
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    9 Sep 04:11pm

    This is must feature as it's adding extra overhead on organization.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    3 Sep 02:59pm

    I work for Nationwide and it seems strange that this facility is not already available. It is configured at the receiving system Connect Direct but in the event of that failing/being unavailable we have to manually change it on SFG

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    2 Sep 07:20am

    Great idea to have alternate comms for automated failover configuration, there is a clear benefit, that can remove unecessary manual intervention and also additional cost/ support wrapper for inclusion of a load balancer. To have this option would benefit the delivery I am working on.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Sep 01:57pm

    Sorry, I should have mentioned that I'm a software engineer working for Nationwide, the customer for which this enhancement is being requested, and I'm working on the project which is replacing one of our legacy applications with a SFG solution. We're very keen on solutions which fail-over automatically and don't need manual interventions to restore service.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Sep 01:39pm

    This feature would be very useful to avoid any interruption to service in the event of the primary C:D node being unavailable.