cancel
Showing results for 
Search instead for 
Did you mean: 

Is BRF(+) the right tool for this job?

Former Member
0 Kudos

Hello everyone,

I've read a number of interesting blogs about BRF and BRF+ some time ago. In a current project, I have some requirements that sound like it might be a good idea to try implementing them using BRF(+). Since I haven't used BRF before, I'm unsure whether this is really a good idea or just a waste of time. I'll try to outline what I want to do:

The focus of the project is the clinical documentation of a certain medical condition. For this, we use a custom-built documentation application which is integrated into the hospital management system (IS-H/i.s.h.med) using standard document management tools. The application is a classic (dynpro) dialog application with some additional controls. The documentation itself is fairly complex (three levels of master-detail tables, over 100 parameters that can be selected or entered). From this documentation, a set of so-called procedures have to be generated. These procedures are basically identifiers that indicate that a certain medical activity was performed. They play an important role in the determination of the total revenue generated by the treatment of the patient. There are supported interfaces to add and modify procedures, and from previous projects I know how to read the current procedures, compare them to the generated procedures that come from some sort of rules engine and issue the appropriate commands to bring the current procedures to the desired state.

I do not yet have a full specification of the rules that will be used to generate the procedures, but from past experience I assume that they will contain stuff like "if a certain flag is set for any of the records in ..., generate procedure X" or "Check all records in table A where column B = C and select the greatest value in column D. With this value, use a mapping table to determine the procedure". To keep things interesting, the rules change at least once a year.

In the past, I've solved this with custom-tailored ABAP coding and customizing tables. This works, but the rule set always requires an experienced developer to adapt it. Even with careful documentation, very few non-coders understand the idea behind the condition and mapping tables. Besides, coding and maintaining a rule set processor is a lot of work. I'd like to try and use the BRF (or BRF+? we're on  SAP_BASIS 701) - do you think that this is a good idea or a waste of time? I'd rather not spend a few weeks trying to bend BRF to do something it wasn't meant to do...

Thanks

  Volker

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Volker,

Your story is a very common one, and from this post it certainly sounds like a valid use case for BRFplus.  If the customizing tables + ABAP is becoming too complex then BRFplus is for sure the better way to go.  However you still need to carefully document your processes and rules in order to take this approach.

Re the Netweaver version, unfortunately I would most likely not use BRFplus on Netweaver 7.01 as it's functionality is still limited due to the age of that release.  However Netweaver 7.02 is extremely functional and 7.03 is even better.  If you can get EHP 2 or 3 applied then it should be fine.  SAP Labs is working on a new feature which would resolve the Netweaver version problem, but I don't know when this will be available.

Hopefully that helps you with your decision making.

Lee

Former Member
0 Kudos

Lee,

thanks for your encouraging answer.

Re the Netweaver version, unfortunately I would most likely not use BRFplus on Netweaver 7.01 as it's functionality is still limited due to the age of that release.  However Netweaver 7.02 is extremely functional and 7.03 is even better.  If you can get EHP 2 or 3 applied then it should be fine.

That appears to be the major problem. We can't upgrade the NW release alone because of the ECC/IS dependencies - we would have to pull the entire stack from ECC 6 EhP 4 to EhP 5, and that's a rather large project for the number of systems involved. My project isn't important enough to warrant that kind of effort, I'm afraid.

However: Not all of our systems use the same software versions. The lowest release we're targeting at the moment is ECC 6 EhP 4, so our central development system is kept at this release. We have one system that is already upgraded to EhP 5, and incidentally, the pilot installation for my project will be on this system. So just a thought: Would it be possible to build the application-specific integration of BRFplus (that is, providing the input data and processing the results) on the central development system on 7.01, ship the project without any rules to the 7.02 system and and then develop the rules on this system? Or are there incompatibilities in the APIs between 7.01 and 7.02?

  Volker

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Volker,

Go for BRFplus 7.02 or higher.

For NW version dilemma. as Lee said "Decision Service Manager" will be released in NW 7.31 SP4 which allow you design rules on latest BRFplus version and deploy into your system NW7.01 remotely.You can use this rules at run time.

There is no question of performance and it will save your time and man force for upgrading platform.

For more detail, I guess you could directly contact Carsten.

regards, Tiwari

Former Member
0 Kudos

Go for BRFplus 7.02 or higher.

I'd love to, but as I said in my reply to Lee, my project isn't important enough to warrant a system upgrade 😞

For NW version dilemma. as Lee said "Decision Service Manager" will be released in NW 7.31 SP4 which allow you design rules on latest BRFplus version and deploy into your system NW7.01 remotely.You can use this rules at run time.

I just talked to one of our basis administrators, and when I mentioned that version number, all I got was laughter... We're the guys actually using the software and digging in the dirt of the old versions, so to speak...

  Volker

carsten_ziegler
Active Contributor
0 Kudos

Hi Volker,

Do you have the chance to get any system in your landscape on NW 731 or NW 703? This could for example also be a Solution Manager system. There are virtually no hardware requirements.
In case the answer is yes, congratulations!

As mentioned above there will be an improvement that allows you to run BRFplus on a central instance. To be more precise, the central instance is a design time system that let's you connect to any of your business applications (on any other system) and build your rules based on the data from the business applications.

Later you deploy the rules into your business systems for local execution. No need to do any upgrade.

This improvement is planned to be made available in Summer. We could demo it already in case you are interested in more details.

BR,
Carsten

Former Member
0 Kudos

Hi Carsten,

I don't think I could convince our system administration to let me use the SolMan for this. However, your suggestion seems to imply that I can use the approach I outlined in my response to Lee: build the application-specific integration of BRFplus (that is, providing the input data and processing the results) on the central development system on 7.01, ship the project without any rules to the 7.02 system and and then develop the actual rules on this system. Is this assumption correct? I think our "internal customers" could live with that limitation - they'd get the documentation right now and the procedure generation only after they have upgraded their systems...

Thanks

  Volker

carsten_ziegler
Active Contributor
0 Kudos

Hi Volker,

what you suggest will not work. What you need is a strong design time part. And that is just not there with BRFplus in NW 701. So you need a system that you can upgrade. There you can model the rules and then deploy them into any older system.

BR,
Carsten

Former Member
0 Kudos

Hi Carsten,

I understand that I need at least a 7.02 system to actually design or build the rules that generate the results I want. Rahul Tiwari mentioned that the Decision Service Manager is able to deploy rules into a 7.01 system, so I assumed that the rules execution engine is present in 7.01, at least in a basic state. It's the "rules designer" UI that is missing in 7.01. However, if the rules execution engine is present in 7.01, this should apply for its API as well - for example, the interface IF_FDT_FACTORY and its implementing class is already present in 7.01. From this I assumed that it should be possible to add the calls from my ABAP application to the BRFplus API (IF_FDT:_FACTORY=>GET_INSTANCE, factory->get_function, context->set_value and so on) on a 7.01 system - knowing that I would not be able to test the entire application on the central 7.01 development system because I can't design the actual rules. I'd just have to transport the entire application to the local 7.02 development system and design the rules there. I admit this might be wishful thinking, partly supported by a quick look into this document and a superficial examination of the classes and interfaces mentioned there.

If this isn't possible, I still have another option - provide a BAdI interface instead of the actual BRFplus integration and then add the BRFplus calls as an implementation of that BAdI on the 7.02 systems.

Still it's good to know that I can in all likelihood achieve what I need using BRFplus and that the target release is my only problem - the answers could have been worse

  Volker

carsten_ziegler
Active Contributor
0 Kudos

You cannot transport rules created with NW702 into a NW701 system. The runtime piece in NW701 is not complete.

The proposal made is to either implement a remote call or better wait for summer and use an improvement called Decision Service Manager (name not final yet). This will allow you to "deploy" the rules into any NW >= 640. Deployment means not that the rules will be transported or so into the target. Instead an executable piece of software will be the result of the deploment. You can use a generic API to execute the rules just like any locally created rules.

Former Member
0 Kudos

You cannot transport rules created with NW702 into a NW701 system. The runtime piece in NW701 is not complete.

I don't want to - maybe I didn't make this clear enough. My intention is to deliver the application on 7.01 without the rules and tell the users "as soon as you're through upgrading your systems, you can use the rules".

Deployment means not that the rules will be transported or so into the target. Instead an executable piece of software will be the result of the deploment.

Since I'm especially fond of code generators, I'm really looking forward to that!

You can use a generic API to execute the rules just like any locally created rules.

This is what I was hoping - I read this as "the API to execute the rules is already in place".

carsten_ziegler
Active Contributor
0 Kudos

OK, then the approach would be to implement the requirements and use a BADI now.

For all BADIs you would then later (either with upgrade or with remote code generation) use BRFplus instead.