Doubt in Execute Rule Set Action

Hi,
I have seen the following documentation in help doc regarding Execute Ruleset action
'The Execute Ruleset and Execute Flow Ruleset rule script actions result in evaluating and executing another ruleset u2013 either a rete ruleset or a flow ruleset. This action is similar to invoking a ruleset, except that the current value of objects, including variable definitions, are available to the ruleset being invoked (instead of their initial values). If the invoked ruleset changes the value of any of the objects, these are reflected in the initial Flow Ruleset'
I have a rule flow set invoking another rule set in its action script. I need to pass a variable defined in rule flow set to invoked rule set. I did this with following action
Execute Ruleset RuleSet1 On var1.
My doubt is how do i access this in invoked rule set? I didnt see this in invoked rule set.
Regards,
Dhana

Hi Dhana,
'The Execute Ruleset and Execute Flow Ruleset rule script actions result in evaluating and executing another ruleset u2013 either a rete ruleset or a flow ruleset. This action is similar to invoking a ruleset, except that the current value of objects, including variable definitions, are available to the ruleset being invoked (instead of their initial values). If the invoked ruleset changes the value of any of the objects, these are reflected in the initial Flow Ruleset'
What we mean by the stmt above is - In case the action "Execute Ruleset" or "Execute Flow Ruleset" is used, all those global definitions which are modified at the ruleset level will retain their changed value when the other ruleset is evaluated.
This needn't be specifically mentioned using the "ON" option.
This option is provided for a user to pass the current value of objects alone. "except that the current value of objects... are available to the ruleset being invoked"
Your other question related to passing the variable definition created at the flow ruleset level, to be passed to the other ruleset - such a mapping is not yet possible. You will have to define this as a common(global) definition.
Hope this clarifies your doubt.
Best Regards,
Arti

Similar Messages

Do you trust the SAP standard rule set ?

Hello all,
I have the impression that, too often, the SAP standard ruleset has been taken for granted : upload, generate and use. Here is a post as to why not to do so. Hopefuly, this will generate a interesting discussion.
As I have previously stated in other threads, you should be very careful accepting the SAP standard rule set without reviewing it first. Before accepting it, you should ensure that your specific SAP environment has been reflected in the functions. The 2 following questions deal with this topic :
1. what is your SAP release ? ---> 46C is different than ECC 6.0 in terms of permissions to be included in the function permission tab. With every SAP release, new authorization objects are linked to SAP standard tcodes. Subsequently some AUTHORITY-CHECK statements have been adapted in the ABAP behind the transaction code. So, other authorizations need to provided from an implementation point of view (PFCG). And thus, from an audit perspective (GRC-CC), other settings are due when filtering users' access rights in search for who can do what in SAP.
2. what are your customizing settings and master data settings ? --> depending on these answers you will have to (de)activate certain permissions in your functions. Eg. are authorization groups for posting periods, business areas, material types, ... being used ? If this is not required in the SAP system and if activated in SAP GRC function, then you filter down your results too hard, thereby leaving certain users out of the audit report while in reality they can actually execute the corresponding SAP functionality --> risk for false negatives !
Do not forget that the SAP standard ruleset is only an import of SU24 settings of - probably - a Walldorf system. That's the reason SAP states that the delivered rule set is a starting point.
So, the best practice is :
a. collect SAP specific settings per connector in a separate 'questionnaire' document, preferably structured in a database
b. reflect these answers per function per connector per action per permission by correctly (de)activating the corresponding permissions for all affected functions
You can imagine that this is a time-consuming process due to the amount of work and the slow interaction with the Java web-based GRC GUI. Therefore, it is a quite cumbersome and at times error-prone activity ...... That is, in case you would decide to implement your questionnaire answers manually. There are of course software providers on the market that can develop and maintain your functions in an off-line application and generate your rule set so that you can upload it directly in SAP GRC. In this example such software providers are particularly interesting, because your questionnaire answers are structurally stored and reflected in the functions. Any change now or in the future can be mass-reflected in all (hundreds / thousands of) corresponding permissions in the functions. Time-saving and consistent !
Is this questionnaire really necessary ? Can't I just activate all permissions in every function ? Certainly not, because that would - and here is the main problem - filter too much users out of your audit results because the filter is too stringent. This practice would lead too false negatives, something that auditors do not like.
Can't I just update all my functions based on my particular SU24 settings ? (by the way, if you don't know what SU24 settings are, than ask your role administrator. He/she should know. ) Yes, if you think they are on target, yes you can by deleting all VIRSA_CC_FUNCPRM entries from the Rules.txt export of the SAP standard rule set, re-upload, go for every function into change mode so that the new permissions are imported based on your SU24 settings. Also, very cumbersome and with the absolute condition that you SU24 are maintained excellent.
Why is that so important ? Imagine F_BKPF_GSB the auth object to check on auth groups on business areas within accounting documents. Most role administrator will leave this object on Check/Maintain in the SU24 settings. This means that the object will be imported in the role when - for example - FB01 has been added in the menu. But the role administrator inactivates the object in the role. Still no problem, because user doesn't need it, since auth groups on business areas are not being used. However, having this SU24 will result in an activated F_BKPF_GSB permission in your GRC function. So, SAP GRC will filter down on those users who have F_BKPF_GSB, which will lead to false negatives.
Haven't you noticed that SAP has deactivated quite a lot of permissions, including F_BKPF_GSB ? Now, you see why. But they go too far at times and even incorrect. Example : go ahead and look deeper into function AP02. There, you will see for FB01 that two permissions have been activated. F_BKPF_BEK and F_BKPF_KOA. The very basic authorizations needed to be able to post FI document are F_BKPF_BUK and F_BKPF_KOA. That's F_BKPF_BUK .... not F_BKPF_BEK. They have made a mistake here. F_BKPF_BEK is an optional auth object (as with F_BKPF_GSB) to check on vendor account auth groups.
Again, the message is : be very critical when looking at the SAP standard rule set. So, test thoroughly. And if your not sure, leave the job to a specialized firm.
Success !
Sam

Sam and everyone,
Sam brings up some good points on the delivered ruleset. Please keep in mind; however, that SAP has always stated that the delivered ruleset is a starting point. This is brought up in sap note 986996     Best Practice for SAP CC Rules and Risks. I completely agree with him that no company should just use the supplied rules without doing a full evaluation of their risk and control environment.
I'll try to address each area that Sam brings up:
1. Regarding the issue with differences of auth objects between versions, the SAP delivered rulset is not meant to be version specific. We therefore provide rules with the lowest common denominator when it comes to auth object settings.
The rules were created on a 4.6c system, with the exception of transactions that only exist in higher versions.
The underlying assumption is that we want to ensure the rules do not have any false negatives. This means that we purposely activate the fewest auth objects required in order to execute the transaction.
If new or different auth object settings come into play in the higher releases and you feel this results in false positives (conflicts that show that don't really exist), then you can adjust the rules to add these auth objects to the rules.
Again, our assumption is that the delivered ruleset should err on the side of showing too many conflicts which can be further filtered by the customer, versus excluding users that should be reported.
2. For the customizing settings, as per above, we strive to deliver rules that are base level rules that are applicable for everyone. This is why we deliver only the core auth objects in our rules and not all. A example is ME21N.
If you look at SU24 in an ECC6 system, ME21N has 4 auth objects set as check/maintain. However, in the rules we only enable one of the object, M_BEST_BSA. This is to prevent false negatives.
3. Sam is absolutely right that the delivered auth object settings for FB01 have a mistake. The correct auth object should be F_BKPF_BUK and not F_BKPF_BEK. This was a manual error on my part. I've added this to a listing to correct in future versions of the rules.
4. Since late 2006, 4 updates have been made to the rules to correct known issues as well as expand the ruleset as needed. See the sap notes below as well as posting Compliance Calibrator - Q2 2008 Rule Update from July 22.
1083611 Compliance Calibrator Rule Update Q3 2007
1061380 Compliance Calibrator Rule Update Q2 2006
1035070 Compliance Calibrator Rule Update Q1 2007
1173980 Risk Analysis and Remediation Rule Update Q2 2008
5. SAP is constantly working to improve our rulesets as we know there are areas where the rules can be improved. See my earlier post called Request for participants for an Access Control Rule mini-council from January 28, 2008. A rule mini-council is in place and I welcome anyone who is interested in joining to contact me at the information provided in that post.
6. Finally, the document on the BPX location below has a good overview of how companies should review the rules and customize them to their control and risk environment:
https://www.sdn.sap.com/irj/sdn/bpx-grc
Under Key Topics - Access Control; choose document below:
    o GRC Access Control - Access Risk Management Guide   (PDF 268 KB)
The access risk management guide helps you set up and implement risk
identification and remediation with GRC Access Control.

GRC53 Rule Set Migrated into GRC10

Gurus, has anyone encountered the following situation. We migrated our 53 rule set into GRC 10 using the Migration Tool. On the surface all of the rule objects seem to move across as they should. We then began to run our risk reports. We noticed that for the same user, in the same backend ECC system, we get varying results from our 53 Rule Set which is in our GRC10 system vs the 5.3 Rule Set executed from our old 5.3 system. We see more violations returned from our old 5.3 system; entire risks are not reported from the GRC10 system.
Consequently, I began reviewing the functions (actions/permissions). I picked a specific risk that was returned by the 5.3 system and reviewed it, line by line - comparing the 53 Rule Set in GRC10 against the 53 Rule Set in the 5.3 system. Everything lined up, with the exception of the activity values. In the 53 Rule Set that was migrated into GRC10 the activity values are single digits (1,2,5, etc) where as in the 5.3 System the activates are two digits (01, 02, 05, etc), Since the values are mainatined in SAP as double digits, could this be causing this? I would hope this is not the culprit, but I am unsure where else to turn.
I will say for those risks that were returned in the results, the activities in those functions were single digits as well.

Hi Penn,
Can you check if your default SoD risk level is "Critical" and hence all the conflicts are not being thrown in 10.0
There is an SAP Note 1632864 where you need to maintain parameter 1024 and se tthe default risk level to High. Since there is no option of All in 10.0 similar to 5.3
Thanks and Best Regards,
Srihari.K

Drop rule set

Hi,
I have only the following object (rule set) on my schema.
OBJECT_NAME     OBJECT_TYPE
DEV_QUEUE_R     RULE SET
I tried to drop with with following syntax:
exec DBMS_RULE_ADM.DROP_RULE_SET(
rule_set_name => 'DEV1.DEV_QUEUE_R',
delete_rules => false);
But following error shown:
ORA-24170
string.string is created by AQ, cannot be dropped directly
Cause: This object is created by AQ, thus cannot be dropped directly
Action: use dbms_aqadm.drop_subscriber to drop the object
And I couldn't find the exact syntaxt of this. Can anyone help me with the exact syntax of DBMS_AQADM.DROP_SUBSCRIBER?
Thanks.
BANNER
Oracle Database 11g Release 11.1.0.6.0 - 64bit Production
PL/SQL Release 11.1.0.6.0 - Production
CORE     11.1.0.6.0     Production
TNS for Linux: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
Edited by: Nadvi on Jul 22, 2010 4:03 PM

Ok, I found the solution.
select * from user_objects;
OBJECT_TYPE OBJECT_NAME STATUS
------------------------------ RULE AQ$WF_DEFERRED_QUEUE_M$1 VALID
RULE SET AQ$WF_DEFERRED_QUEUE_M$1 INVALID
1.Set the following event at session level:
alter session set events '25475 trace name context forever, level 2';
2. Drop rule:
execute DBMS_RULE_ADM.DROP_RULE('.AQ$WF_DEFERRED_QUEUE_M$1',TRUE);
commit;
3.Drop rule set :
execute DBMS_RULE_ADM.DROP_RULE_SET('AQ$WF_DEFERRED_QUEUE_M$1');
commit;
4. Connect as SYSTEM or SYSDBA and try to drop user again.
drop user <user> cascade;
Thanks

Mulltiple Rule Sets in GRC 10.0 for one System

Hi All,
We do have 2 different companies working on one system and by that 2 different rule sets that are applicable.
Due to that we are facing different problems we don't know how to solve yet but lets start with the first one dealing with the rule set that should be used in the access request.
We want to determin which rule set should be used over the requested role (e.g. if role name contains 0001 use rule set 0001, if role name contains 0002 use rule set 0002).
We have alerady tried several different senarios in BRF+ without success.
Does anybody have a solution or at least an idea for this topic?
Thank you all very much in advance!
Eva

Hi Ashish ,
Thanks for your time . Let me explain you my requirement and would really appreciate if you would have some inputs here which would help me to design this .
The actual client requirement is to design a CUP Workflow and If there are SOD issues identified, the workflow will need to go to a central team for them to address each issue. If this group decides to apply mitigating controls to the issues, the workflow must then go to the compliance group for them to review for appropriateness. Requirement is do a SoD analysis for every role change/add request , so that this group takes the appropriate action based on the SoD Analysis . For all my CUP request raised , i want system to do a SoD analysis and let this group know whenever there is a SoD found or just end the workflow if there is no risk.
I am aware of the Risk analysis process for GRC 10.0 , however i want it to happen as a part of this work flow requirement.
The requirement is to configure the access request work flow so that the end goal of work flow is just facilitation of an SOD review. I hope i was able to explain my requirement . Thanks again for your help.
Your valuable guidance would be really appreciated.
Vikas

Deployment Rule Set broken with Java 7u55

Hello!
I'm using Deployment Rule Set in my company environment, its signed by code signing certificate that is given out by internal CA. After I upgraded to Java 7u55, the Deployment Rule Set does not recognize older statically installed Java version.
Versions I have:
7u45 - install directory: C:\Program Files\Java\jre1.7.0_45
7u51 - install directory: C:\Program Files\Java\jre1.7.0_51
7u55 - install directory: C:\Program Files\Java\jre1.7.0_55 or C:\Program Files\Java\jre7\ - neither does not work
When I go to site described in Ruleset and that has to use Java 7u45, then I receive an message "Deployment Rule Set required Java version 1.7.0_45 not available. In the same way it doesn't recognize 1.7.0.51 or even Java version 6.
When I uninstall Java 7u55, everthing works fine again.
My ruleset looks like this:
<ruleset version="1.0+">
     <rule>
          <id location="first.site.com" />
          <action permission="run" version="1.7.0_45" />
     </rule>
     <rule>
          <id location="second.site.com" />
          <action permission="run" version="1.7.0_51" />
     </rule>
     <rule
          <id />
          <action permission="default" />
     </rule>
</ruleset>
Anyone knows what's wrong or is it a bug?

costlow - I disagree. If I'm using IE, then I only need the internal certficate used to sign the jar to be also insalled on the machine in question in the windows CA Certs store. If the cert was the issue, why does it work with 7u51. If it was a bad cert, it should fail with every version. Plus, I think the pop up has a different error message if it has a cert issue.
I'm having the exact same issue as the OP described and it all started with 7u55. Here's what I've found:
- With 7u55 or 7u60 installed, the error will come up rergardless of what prior version is being requested.
- If 7u51 is the latest installed, it works
- If 8u05 is installed with 7u55 and/or 7u60, it works
- If I install the 7u60 EA b15, it works
Something in the final release is being added that blocks this functionality, but for some odd reason only in the 7 family starting with 7u55.
Any insight you could give would be very helpful. In the meantime, I am deploying 8u05 to cover this up, but it does pose issues for some apps that don't work with the new 8 family plugin.

How to migrate Master Data (Rule set etc.) from GRC 5.3 to 10.1 without using the "Migration Tool"

Greetings,
We are currently on GRC 5.3 SP 18 (Java ONLY) and migrating to GRC 10.1. I referred the Migration Guide which outlines that GRC 5.3 needs to be upgraded to SP 20 as pre-requisite for using the "Migration Tool" . Our BASIS team is reluctant to perform this upgrade from SP 18 to SP 20.
Having said thus, I'm exploring options of migrating data from 5.3 to 10.1 without using the "Migration Tool:.
Rule set Migration:
I'm in the process of preparing the 9 different files (listed below) and later utilize the "Upload Rule" option for migrating the Rule set data from 5.3 to 10.1.
While I'm able to gather data for most of the files I'm not sure how can I obtain the data pertaining to the two files (Function Actions and Function Permissions) underlined and highlighted in Red below.
1. Business Process
2. Function
3. Function Business Process
4. Function Actions
5 .Function Permissions
6. Rule Set
7. Risk
8. Risk Description
9. Risk Rule Set Relationship
10. Risk Owner Relationship
Can someone please enlighten me and share their experience with regards to this exercise. Really appreciate your help !
- Janantik.

I have done this successfully before. Because you are having issues, I would NOT recommend using the migration tool to move the ruleset. Instead:
1. Download the ruleset files from 5.3
2. The 5.3 tcode-permission file, which defines which tcode permissions from SU24 need to be checked during risk analysis, needs to be split into the two files you mention above in red.
FUNCTION_ACTION : this file represents S_TCODE objects and TCD fields mapped to each function (Function to Tcode relationship). In the 5.3 file, you will filter on object S_TCODE and field TCD, and you will get a complete list that now represents "FUNCTION_ACTION". BUT instead of having all the jumbled permission info, you will just have 3 columns: Function - Tcode - Status.
3. The remaining permissions that are left over, after taking out the S_TCODE -TCD items, represent the "FUNCTION_PERMISSION" file in GRC 10.
4. Manually create the excel spreadsheets for each file.
5. Copy and past each sheet to a unique .txt file.
6. Upload the ruleset manually through SPRO-->GRC-->Access Control-->Access Risk Analysis-->SoD Rules-->Upload SoD Rules.
7. Select each file and then upload to the correct Logical Group.
This is a huge pain, but it works. Let me know how this goes and if you need any assistance.
-Ken

Multiple GRC rule set update

we are having a custom rule set A loaded in GRC. Now we want another rule set B, with new risks and definition to be loaded in GRC. If we try to upload rule set B risks and functions via Upload function in GRC, would it overwrite the rule set A, or not.Just wanted to confirm whether existing rule set A would be affected or not, due to upload of rule set B.

Hey Alpesh,
Sorry, I haven't understand it correct. This is a question that will always be asked in the train.
You wrote:
"If you have created different files (e.g. risks, ruleset, function action, function permission etc.) and upload them via configuration -> rule upload then RAR will not overwrite your ruleset A and will only insert new rule set files."
Is this just possible, if all IDs (risk, function, function action, function permission) will be changed before and could not be equal like in the rule set A? correct?
What's about with the ALL.txt files, do I have to change/upload them as well again?
Thanks for feedback,
alwaly a pleasure!
Greets
Martin

Risk Analysis at user level shows nothing in all 3 views though at role level shows risks of global rule set

I am configuring ARA 10.1 for a ECC 6.0 plug in development system and facing this issue. Risk Analysis at user level shows no data in all 3 views though at role level shows risks of global rule set. I am using Global rule set. I generated all risks/functions & using connector group as SAP_ECCS_LG not SAP_R3_LG.I activated common, R/3 & ECCS BC sets. Added integration scenario for AUTH. Run all 4 sync jobs multiple times successfully. My system already has decentralised EAM 10.1 implemented & even used in production as BAU. I have checked at both chrome & IE. The misleading thing is that RFC is also working fine & I can see risks in Risk Analysis at role level & risky roles are even assigned to valid users.GRC is at SP4 & accordingly is the ECC 6.0 plug in. Thanks in Advance. Please consider it urgent.

Hi,
Assign ECC connector to SAP_ECCS_LG group.
Run the programs GRAC_PFCG_AUTHORIZATION_SYNCand GRAC_REPOSITORY_OBJECT_SYNC) in full synch mode(this might take time so better do this in background). Better do it sequentially.Check the logs of the jobs in SLG1 just to ensure everythings fine.
Run ARA for a specific user and mention the connector for faster output. Ensure this user has the role with risks.Also as explained earlier check the GUID against user id in table GRACUSERROLE and using GRACROLE you can find out the technical name of the role updated in the table. This should be same as the backend role.
Then run ARA and while doing so please ensure the selection screen doesnt have any unwanted default inputs. If followed correctly , this should be of help. I am assuming the role analysis yielded correct risks as configured since this would mean that connector have correct actions and basic config is in place.
Regards,
Vivek

CC / RAR Rule Set Build

We had a rule set built in Compliance Calibrator 5.2 by a vendor during implementation. We have over 700 rules and now know that there are too many rules in our rule set.
Can any of you tell me the best way to build a rule set? How many rules do most people have in their rule set? Is there a best practice out there somewhere to do this?

Hi Greg,
You will have to understand relationship between rule, risk, business process, function, transaction and permission to build a rule from scratch. If you need to build one or two rules, you can just go through CC and do it. If you want to build large set of rules then you will have to create text files for risks, functions, rules etc. I will recommend you go through the config guide for CC 5.2 or 5.3 and see how rules are being built.
There is no straight answer on the number of rules. The number rules you need will depend on industry, company size, location, rules and regulations to follow, company structure etc. Best practice rules come with the installation and you can always get them from SAP. Best practice ruleset contains around 40,000 action and permission rules.
Regards,
Alpesh
SAP GRC Manager (PwC)

SAP GRC 5.2 Compliance Calibrator rule sets for HR module

HI All,
The company i am working for has done installation of GRC 5.2. I would like to download the SAP out of box Compliance Calibrator rule sets for HR function module in a spreadsheet format.
I would like to download the rule set for risks at Function level, Tcode level and also at authorization object level in ABAP and Roles, actions and permissions in JAVA.
I will discuss with the BPAs, internal auditors and come up with a new rule set exclusively for my company needs with the help of the above spreadhseet.
Please tell me what steps i need to do to get this thing done.

Please go through the process but save these as txt files for UNIX. I am not sure about 5.2 but CC4 was not uploading rule files correctly if file was not saved for TXT for UNIX.
Regards,
Harry Sidhu

For GRC 5.3 can I use the SAP GRC 5.2 rule set

We are going for an upgrade to GRC 5.3, I have a small concern here....
Can I use the same ruleset what I used in GRC 5.2 to SAP GRC5.3 ...?
because when I checked ruleset at permission level in GRC 5.2 it displays first object of an action from one function conflicting with first object of an action from another function, where as in GRC 5.3 it displays all objects of an action from one function vs all objects of an action from another function....
How will it impact analysis in GRC 5.3 with old rule set...?
appreciate your response & thanks in advance.

Hi,
Here you will find the documentation to get Upgrade/Configuration Guides.
[https://websmp103.sap-ag.de/~form/sapnet?_SHORTKEY=01100035870000718172&]
SAP BusinessObjects Governance --> Access Control ---> SAP GRC Access Control 5.3
There you will find a Upgrade guideline.
Cheers,
Martin

A simple problem? - cannot grant create rule set

Hi,
Can anyone spot the stupid mistake i'm obviously making when trying to grant create rule set to my streams admin user? The script was working last week?!
BEGIN
DBMS_RULE_ADM.GRANT_SYSTEM_PRIVILEGE(
privilege => DBMS_RULE_ADM.CREATE_RULE_SET_OBJ,
grantee => 'strmadmin',
grant_option => FALSE);
END;
ERROR at line 1:
ORA-00931: missing identifier
ORA-24000: invalid value , USER/ROLE should be of the form [SCHEMA.]NAME
ORA-06512: at "SYS.DBMS_RULE_ADM", line 167
ORA-06512: at line 2
Many thanks,
Warren

Yes, catpatch.sql is necessary only for existing 9.2.0.1 databases upgraded to 9.2.0.2.
I am assuming that when you created the database under 9.2.0.2 that catalog.sql and
catproc.sql were run. The next step, I guess, is to turn on sql tracing to see
which sql statement actually fails when you run the command. Turn on sql tracing
with the following command, and then execute the procedure again.
alter session set sql_trace=true;

Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA

Issue Summary
In Java 1.7 Update 71, Java 1.7 Update 72 and Java 1.8 Update 25 Deployment Rule Sets do not properly launch the latest available version from the JRE6 family when the jpi-version is specified by the RIA. We've noticed this with Oracle Forms and Reports 11g where we have forms that specify Java 1.6 Update 20. We used to be able to specify Java 1.6 Update 26 in our Ruleset, but now the only version a that works in our ruleset is Java 1.6 Update 20 which is the same version requested by the JPI-Version attribute of the jar. The long term solution would be to upgrade Oracle Forms and Reports, however this isn't currently in the cards.
RuleSet.xml Test
Ruleset.xml
1
2
3
4
5
6
7
8
9
10
11
<ruleset version="1.0+">
<rule>
   <id location="*.javatester.org" />
   <action permission="run" version="1.6*" />
</rule>
<ruleset version="1.0+">
<rule>
   <id location="*.internaldomain.name" />
   <action permission="run" version="1.6*" />
</rule>
</ruleset>
Test 1 (Control)
Installed Java Versions:
– 1.7 Update 51 b13 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
Deployment Ruleset works as expected for both URLs
Test 2
Installed Java Versions:
– 1.7 Update 72 (both x86 and x64 however x86 is invoked)
– 1.6 Update 26 b03 (both x86 and x64 however x86 is invoked)
The RuleSet works for JavaTester.org however on internaldomain.name we get the following error:
With the trace logging turned on, I suspected the version attribute supplied by the RIA. I was able to trick Java by adding the following to my system deployment.properties file:
deployment.javaws.jre.0.product=1.6.0_20
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.enabled=true
Because the RIA requests 1.6.0_20 it matches 1.6* from the deployment ruleset sooner than 1.6.0_26. However, if 1.6.0_20 is not available 1.6.0_26 should match according to the Deployment Rule Set documentation:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
The version of the JRE that is used is determined by the following order of precedence:
1. The current version of the JRE is used if it is available and matches both the version attribute and the version requested by the RIA.
2. The latest available version of the JRE is used if it matches both the version attribute and the version requested by the RIA.
3. The current version of the JRE is used if it is available and matches the version attribute.
4. The latest available version of the JRE is used if it matches the version attribute.
If no version is available that meets the criteria, then the RIA is blocked, and a message is shown to the user. To provide a custom message, include the message element.
As a result:
If Java 1.6.0_20 is listed in the version requested by the RIA and 1.6.0_20 is listed in the deployment.properties file, #1 matches.
If Java 1.6.0_20 is listed in the version requested by the RIA, but 1.6.0_20 is NOT listed in the deployment.properties file the #1 SHOULD match, but doesn’t. It used to match up-to and including JRE 1.7 Update 51 however the ruleset appears to no longer match in subsequent versions.
#2 should never match with our current Deployment Ruleset. It would match if we specified 1.7* as a version in the Ruleset.xml.
#3 used to be broken as well after JRE 1.7 Update 51 however this bug has been marked as fixed. See: http://bugs.java.com/view_bug.do?bug_id=8032781
I have reproduced this issue with Java 1.7 Update 71, Java 1.7 Update 72, and Java 1.8 Update 25 when one of these versions are installed with Java 1.6 Update 26.

I can't seem to edit this post anymore, for some odd reason.
So here goes;
I found this post in NVIDIA's knowledge base;
When installing an after-market graphics card into a certified Windows 8 PC with UEFI enabled, the s...
The interesting parts in this post are as follows;
When an after-market graphics card is installed into a motherboard with UEFI enabled in the system BIOS, or if the system is a certified Windows 8 PC with Secure Boot enabled, the system may not boot.
UEFI is a new system BIOS feature that is provided on most new motherboards. A UEFI system BIOS is required in order for the Windows 8 Secure Boot feature to work. Secure boot is enabled by default on certified Windows 8 PCs.
In order to get the PC to boot with a graphics card that does not contain UEFI firmware, the end-user must first disable the secure boot feature in the system's SBIOS before installing the graphics card.
Note: Some system SBIOS's incorporate a feature called compatibility boot. These systems will detect a non-UEFI-enabled firmware VBIOS and allow the user to disable secure boot and then proceed with a compatibility boot. If the system contains a system SBIOS the supports compatibility boot, the user will need to disable secure boot when asked during boot process
This leads me to believe that the BIOS update that wrecked my setup was 9SKT58A/9SJT58A, which only contains one change;
"Adds support for updating BIOS from a WIN7 BIOS to a WIN8 BIOS".
I've just ordered a cheap UEFI-compatible GT640 from Gainward, so I hope I'll be able to try that out this weekend.

SoD rule set Download issue

Hi All,
While downloading the SoD rule set (Global), I am not getting the data for Function-Action and Function-Permission, except these, rest of the data are coming.
But, I can get to see these data under tables: GRACFUNCACT and GRACFUNCPRM.
so obviously we can't have these data exported from table and to get converted into .txt format to upload SoD.
GRCFND_A is at SP14.
Please help in getting this issue resolved.
Thanks,
Ameet

Hi Ameet,
You have to reactivate it each time you install a SP in order to get the updates.
If you develelop your own SoD ruleset you wont use the SAP standard functions and risk, so reactivate the BC Set wont cause any problem.
If you change the standard functions and risks (which is wrong) such changes will be overwritten when reactivate the BC Set.
After reactivating the BC set you'll be able to download SoD rules fom the logical system SAP_R3_LG.
Cheers,
Diego.

Doubt in Execute Rule Set Action

Similar Messages

Maybe you are looking for