BRF+ and version control/branching

[former_member277448]

hello

we have a situation that I am looking for some advice on.

we have a BRF+ application that has been developed and deployed to production.

we are currently making some changes/enhancements to rules for a future deployment.

in the mean time some defects have been reported with the rules in production and need to be resolved ASAP.

now, we cannot make the changes in dev as it contains the future changes and they are not ready yet to go live.

there are many future changes made so a roll-back is not practical.

in other technologies (eg Java) we would use source control software such as Subversion to create a dev branch for the future changes and use a defect branch for the fixes, and then merge the fix branch with the dev branch.

so, my question is ... can we do something like this in BRF+? If not, can you suggest an option for us?

thanx in advance.

cheers

pas.

[christianlechne]

Hi Pas,

you have versioning within BRF+. The versioning has several option like "off" (no versioning), "on" (versioning whenever you save) and "transport dependent" (so a version is created whenever a transport is released). Details can be found here: Versioning - Business Rule Framework plus (BRFplus) - SAP Library

What is not possible is to create branches and merge them afterwards (like in subversion or GIT). The versioning of BRFpülus objects is comparable to the versioning of ABAP objects.

Do you really make your future dev and your maintenance/error fixing in the same track of SAP systems? Usually you have two separate system tracks as your scenario also causes trouble in ABAP development.

One furtther questions: Do you have versioning completly switched off?

Maybe you can use XML-Eport to save the development you already made, build it back and do an import afterwards (be aware that then you have to do the fixes again after import)

BR

Christian

[former_member277448]

Hi Christian.

Thanx for the quick reply.

We do not use versioning in our BRF+ development - I have not been able to get a satisfactory answer why we do not - we just don't.

when you say 'same track of SAP system' I am not sure what you mean? do you mean same package? is a 'track' similar to a branch? how do we create/employ different tracks?

re the XML import information - are you suggesting something like

• create an export before making any changes to have a 'clean' copy
• export changed dev code
• import clean code, make fixes and deploy
• import saved dev code to continue future development

once again, thank you for your quick response.

cheers

pas

[christianlechne]

Hi Pas,

concerning track I meant that usually you have a dev, a test and a quality system that delivers to production and in parallel a maintenance track with a dev and a test system that delivers the fixes to production (this is the simplest setup for doing SAP development). Anyway if you do not have that in place, this does not lead us anywhere

Concerning the XML workaround, you have the following option in your system:

Start point is that you have an unfinished development in place without the corrections you want to do. In order to avoid dependencies I would do an XML export of your current development of your current development to save it. Then "remove" all the new development (and only that stuff) putting the system to a situation corresponding to your productive environment, make your correction and ship it to production. Then import the backup again to your dev system.

Please be aware of the following points:

• Check if the XML export and import work properly, as this functionality is very error prone
• Make sure that the "old state" on your dev system correponds to the state on the productive system before you ship it in order to avoid inconsistencies
• Make sure that the correction is applied if you import of your backup is done, as otherwiese the final delivery to production will again miss the correction

I do not know how much development was done in your project and how it is structured etc., so maybe you can even avoid the XML import by deactivation of your new develoment. This would be possible if your complete new development is encapsulated in one or several rules or rulesets that you can directly switch off, so that they are not executed. Onother option might be the usage of preconditions 

Anyway any of the options described above is definitly a workaround and to a certain extent bound to a risk that things might go wrong and mess up your system.

BR

Christian

P.S. I would heavily recommend to overthink your system landscape to allow corrections without "workarounds"