SAP Primary Adapters require a Message Flow to be stopped pror to redeployment

Hello,

Firstly, please accept our apologies for the automated comment which appeared in the ID field of the RFE stating "This request is a duplicate of an internally tracked request that is not currently available on the site. Please contact us to migrate the request to the site." Please rest assured that you do not need to take any action here. There is a back-end process which runs behind the RFE system which attempts to automatically link the original RFE with the duplicate RFE. In this case that reconciliation process has experienced a problem which we will attempt to investigate.

On the wider topic of the last commented updated from 16th October, and the relationship between this RFE 93446 and the suggested duplicate RFE 32900 ...

We agree with your assertion that although the symptoms of the two RFEs both relate to SAP adapter use cases, they are slightly different. 93446 complains that primary adapters require a flow to be stopped before redeployment where as 32900 complains that secondary adapters require cross-container scope and isolation.

We marked 93446 as a duplicate in an attempt to be helpful and gain traction on common architectural ground between two separate use cases. Sorry this seems to have caused more confusion for you. Please allow us another attempt at explaining how we saw the linkage ... Our understanding of this RFE 93446, is that fundamentally you liked the behaviour of WMBv7 where primary adapters could be redeployed without stopping flows first. Through the product releases that have followed WMBv7 from 2011 onwards, the product architecture has gradually moved away from this model. In WMBv8 (2011), applications were introduced which when changed are redeployed as a "sealed unit", rather than a "delta deploy" model like the content from integration projects in WMBv7 which was deployed to the top level integration server as a shared area of scope. IIBv10 (2015) and its introduction of shared libraries provided an avenue forward for users who like the flexibility of separately isolated application scopes, but with the benefit of shared artifacts that the separate areas of scope can both see. Unfortunately for adapter node users, we have not yet provided support for adapter models in shared libraries. ACEv11 (2018) moves the product further away from the model of top-level deployed artifacts - you can still deploy these artifacts but they are placed into a top level application for you ... so if you redeploy top level content then all of that top-level "default application" content is replaced. So, there is a common thread here between 93446 and 32900 related to the freedom of deployment of adapter component and flow. If and when 32900 is implemented, and primary / secondary adapters were allowed in shared libraries, then our thinking was that this solution would allow you to separate your message flows from your adapters and allow you to independently update them. This is the reason why the duplication was marked.

On this topic of discussion it is also worth highlighting another RFE 27278, which is not specifically about adapters, but is also requesting "delta deploy" of message flows within an application scope. Essentially this is asking for a return of the WMBv7 model, but within an application area of scope rather than the whole integration server. As noted in the comment on that RFE, in general with the move to container architectures, there is less demand for this kind of concept given that when using container frameworks the ability to make dynamic changes to a running container is less important than simply shutting down an existing container, changing the configuration and spinning it up again, or in fact have more isolated containers with less in each.

We are happy to keep this RFE 93446 open and treat all three RFEs mentioned above as separate items if you would prefer. Our aim with marking duplicates is purely an attempt to help find common architectural ground between RFE use cases so that we can delight the largest number of our users by gathering support for investment in high-value features which benefit the greatest number of areas as possible at the same time. For low-voted RFEs with very specific narrow use cases, this can be a helpful way of increasing their chances of implementation. Either way, the comments now on these RFEs will at very least link the ideas together when the RFEs periodically return for further consideration.

We are re-opening this RFE unless or until we hear otherwise.

I don't understand the updates here at all.

As far as I can tell, the linked RFE has nothing to do with this RFE... This RFE (93446) is concerning Primary Adapter functionality and a basic change in dependency that occurred between Message Broker and IIB architectures (a change for the worst from the perspective that I have illustrated).

RFE 32900 is concerning Secondary adapter functionality and scope. Both might have been brought about by the same architectural changes, but they each have their own merits and I don't believe that they are linked at all.

Also - the headline of this RFE has been updated with "This request is a duplicate of an internally tracked request that is not currently available on the site. Please contact us to migrate the request to the site."
...this is both in contradiction to the comment update (linking this RFE to another) and unhelpful - why make me contact you to make something you have available internally available on this site? The contact link you supplied requests that I select from a range of topics which aren't applicable, and finally a contact group - again, how would I know who should pick this up?

RFE Review. Thank you for raising this RFE and despite our direct communications via email and face to face over the years, apologies for the time period the RFE has been in Submitted Status. The root cause of the scenario presented is a combination of the architectural move towards the now strategic Applications, Libraries and Shared Libraries, in combination with the restricted support of adapter models only being allowed in Static Libraries and not Shared Libraries. This aspect of future behaviour is being tracked under RFE 32900:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=32900
Status of this RFE is closed as a duplicate.