I have recently authored an article for the WebSphere Support Authority portion of Developer Works. It's a general overview of RAFW describing each of the supported modes. Hope you find it useful.

http://www.ibm.com/developerworks/websphere/techjournal/1007_supauth/1007_supauth.html

--tim

Thanks! definitely useful. I'm just starting out with WebSphere. Any information helps a lot. :D

Hey Tim,

First, I want to say that you and Brent are two of the best at explaining RAFW/BF concepts, and to thank you both for your quick and useful responses in the past.

That said, with the dis-integration between RAFW and BF into separate stand-alone products beginning with RAF v3 and BF v7.1.3, can we look forward to some articles on how to point existing BF/RAFW projects to the new RAF with minimal pain?

Also, will there be a new Jazz forum for RAF, or will that still remain here?

Thanks!

Hey Tim,

First, I want to say that you and Brent are two of the best at explaining RAFW/BF concepts, and to thank you both for your quick and useful responses in the past.

That said, with the dis-integration between RAFW and BF into separate stand-alone products beginning with RAF v3 and BF v7.1.3, can we look forward to some articles on how to point existing BF/RAFW projects to the new RAF with minimal pain?

Also, will there be a new Jazz forum for RAF, or will that still remain here?

Thanks!

I would suggest that you take a look at the following area of the Rational Automation Framework (RAF) 3.0 InfoCenter on migrating from an existing Build Forge/RAFW to the new RAF:
http://publib.boulder.ibm.com/infocenter/rafhelp/v3r0/index.jsp?nav=/6

RAF contains a private embedded Build Forge that is used so the process of migrating is fairly straight forward. To be clear, you will not be invoking the new RAF from the old existing BF/RAFW but rather porting the configuration to be new RAF.

There will not be a new Jazz forum for RAF, we will continue to use this forum for handling questions about the product. If or when there is ever a change in what forum to use, we will make sure to post about it ahead of time so folks can be aware.

Thanks David,

Maybe I'm missing something, but the migration path suggested seems to leave a number of issues unaddressed on the Build Forge side. RAF is only one of many ways in which we use Build Forge EE.

It would seem that given the separation of the two products, the built-in RAF version of BF would almost always be a bit behind the EE version.

Also, given the separate paths being taken by the two products, there is no assurance that the built-in RAF version of BF would continue to support all features of the full version.

We have moved int the direction of making BF a critical part of our maintenance and deployment structures in a number of ways not related to RAF.

We have integrated BF through the API with Lotus Notes such that jobs are automatically run based on form state. We are in the process of moving all of our Main Frame deploys through Build Forge, planning future integration of BF with PanValet and a third-party scheduler, etc.

Another issue that is not addressed is custom actions that we have written for RAFW that would have to be moved to RAF or rewritten.

We can't afford to risk a loss of full EE Build Forge capabilities for the sake of RAF, so I'm not sure using the embedded BF is a safe way for us to go. For us, RAF is a useful add-on to BF more so than BF being a useful way to work with RAF.

BTW, Feel free to move this thread to the main forum area if you like. It probably is starting to be clutter in this folder.

Thanks,
Jonas

Thanks David,

Maybe I'm missing something, but the migration path suggested seems to leave a number of issues unaddressed on the Build Forge side. RAF is only one of many ways in which we use Build Forge EE.

It would seem that given the separation of the two products, the built-in RAF version of BF would almost always be a bit behind the EE version.

Also, given the separate paths being taken by the two products, there is no assurance that the built-in RAF version of BF would continue to support all features of the full version.

We have moved int the direction of making BF a critical part of our maintenance and deployment structures in a number of ways not related to RAF.

We have integrated BF through the API with Lotus Notes such that jobs are automatically run based on form state. We are in the process of moving all of our Main Frame deploys through Build Forge, planning future integration of BF with PanValet and a third-party scheduler, etc.

Another issue that is not addressed is custom actions that we have written for RAFW that would have to be moved to RAF or rewritten.

We can't afford to risk a loss of full EE Build Forge capabilities for the sake of RAF, so I'm not sure using the embedded BF is a safe way for us to go. For us, RAF is a useful add-on to BF more so than BF being a useful way to work with RAF.

BTW, Feel free to move this thread to the main forum area if you like. It probably is starting to be clutter in this folder.

Thanks,
Jonas

Jonas,

The built-in version of Build Forge for Rational Automation Framework (RAF) will match the needs of the RAF product rather than always being the latest and greatest version of Build Forge. The built-in version of Build Forge for RAF does not have any technical features disabled but is limited in it's usage based on the tasks it is automating (this is detailed in the license agreement).

The way that we are having teams approach this is to separate out the RAFW (RAF) functionality into a separate server instance backed by a separate set of database tables. This can be done by "migrating" the data from Build Forge into the new RAF instance and removing projects that are not related to the middleware management automation.

The idea is to not force you to choose one or the other but rather to allow you to use both, though as separate instances - that way you can do automation processes that are not related to middleware management in BF and middleware management activities in RAF.

The Build Forge API still exists in RAF and is not different than the one in the standalone Build Forge so you should still be able to interact with Lotus Notes as you have already been doing.

Also, custom actions can be ported to the new RAF instance and will continue to work (assuming that you have the custom actions stored in the user section of the RAFW directory structure).

Again, I'm not suggesting that you use one tool or the other but rather that you separate out the usage scenarios to the different products as appropriate for the type of activity they perform.

Got it. Thanks! That we can do.

Thanks David,

Maybe I'm missing something, but the migration path suggested seems to leave a number of issues unaddressed on the Build Forge side. RAF is only one of many ways in which we use Build Forge EE.

It would seem that given the separation of the two products, the built-in RAF version of BF would almost always be a bit behind the EE version.

Also, given the separate paths being taken by the two products, there is no assurance that the built-in RAF version of BF would continue to support all features of the full version.

We have moved int the direction of making BF a critical part of our maintenance and deployment structures in a number of ways not related to RAF.

We have integrated BF through the API with Lotus Notes such that jobs are automatically run based on form state. We are in the process of moving all of our Main Frame deploys through Build Forge, planning future integration of BF with PanValet and a third-party scheduler, etc.

Another issue that is not addressed is custom actions that we have written for RAFW that would have to be moved to RAF or rewritten.

We can't afford to risk a loss of full EE Build Forge capabilities for the sake of RAF, so I'm not sure using the embedded BF is a safe way for us to go. For us, RAF is a useful add-on to BF more so than BF being a useful way to work with RAF.

BTW, Feel free to move this thread to the main forum area if you like. It probably is starting to be clutter in this folder.

Thanks,
Jonas

Jonas,

The built-in version of Build Forge for Rational Automation Framework (RAF) will match the needs of the RAF product rather than always being the latest and greatest version of Build Forge. The built-in version of Build Forge for RAF does not have any technical features disabled but is limited in it's usage based on the tasks it is automating (this is detailed in the license agreement).

The way that we are having teams approach this is to separate out the RAFW (RAF) functionality into a separate server instance backed by a separate set of database tables. This can be done by "migrating" the data from Build Forge into the new RAF instance and removing projects that are not related to the middleware management automation.

The idea is to not force you to choose one or the other but rather to allow you to use both, though as separate instances - that way you can do automation processes that are not related to middleware management in BF and middleware management activities in RAF.

The Build Forge API still exists in RAF and is not different than the one in the standalone Build Forge so you should still be able to interact with Lotus Notes as you have already been doing.

Also, custom actions can be ported to the new RAF instance and will continue to work (assuming that you have the custom actions stored in the user section of the RAFW directory structure).

Again, I'm not suggesting that you use one tool or the other but rather that you separate out the usage scenarios to the different products as appropriate for the type of activity they perform.