Profile # "Concurrent: Report Access Level"
The user profile option "Concurrent:Report Access Level" determines report output file and log file access privileges for your end users. As System Administrator, you can set this profile option to either "User" or "Responsibility."
If you set the "Concurrent:Report Access Level" option to "User", the user can only view the requests submitted by him.
If you set the "Concurrent:Report Access Level" option to "Responsibility" at the User level, that user can also review the log and report output files from all requests submitted from the current responsibility.
If you set the "Concurrent:Report Access Level" option to "Responsibility" at the Responsibility level, any user of that responsibility can also view the log and report output files from all requests submitted by any other user of that responsibility.
This profile option is visible and updatable at the site, responsibility,
and user level
Technical Diffrence between 11i and R12
MO_GLOBAL-Dive into R12 Multi Org Design
A few questions come to mind when we think about Multi Org in R12. The best way to analyse those questions is by opening package MO_GLOBAL. How is CLIENT_INFO being replaced in R12?
Let’s take an example.
In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info"But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL select * from all_policies where object_name='PO_HEADERS'
e. The effect of this policy is that, whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)
Also see **** below, latter
Does this mean, if I create a new custom table, I will have to apply RLS [Row Level Security] against Custom table too?
Yes indeed, if it contains data partitioned by ORG_ID. All you need to do in such case is to assign package function MO_GLOBAL.ORG_SECURITY to that table/synonym/view.
Will the Multi Org Row Level security be applied against the table or the synonym or the view?
In theory, RLS can be applied against any of the above objects. However in practice, you will apply RLS against Objects in APPS Schema. This means, you will most probably apply RLS on Synonyms. Basically, the Multi Org Views are now replaced by RLS Secured Synonyms. Hence no code change is required where the pre-R12 Multi-Org secured view was being accessed. The responsibility of securing data as per ORG_ID now lies with RLS [also known as VPD - Virtual Private Database].
I have made changes to my Multi Org Security Profile, by attaching a new Org Hierarchy. Do I need to run any process?
Just like we do in HRMS, it is advised that any changes to Security Profiles must be followed by running "Security List Maintenance"What is MO_GLOBAL.INIT
Purpose of mo_global.init :-
It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used.
If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmpWhen & from where is mo_global.init called ?
This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZEIs mo_glob_org_access_tmp table a global temporary table?
Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile]What is the purpose of MO_GLOBAL.ORG_SECURITY?
The purpose of Row-Level-Security is to hide certain data [based on some conditions]. RLS does so by appending a where clause to the secured object.
End User Step 2:
You can double check the created Supplier, which has Supplier Number 20186.
This supplier number comes from a table named AP_SUPPLIERS.
The registry id that you see is the Party_number field
from hz_parties [TCA Party Table]
Now, lets have a look at the list
of tables impacted by
creating the above Supplier record.
I am not saying that inserting into below listed tables is the way to create
Suppliers in R12 TCA Model [Use API's for that].
This article is purely for your understanding of the new data model for
Suppliers in R12 TCA.
Of course this will also be helpful to you when developing reports in R12.
Table HZ_PARTIES
SELECT * FROM hz_parties WHERE party_name= 'Go4Gold' ;
This happens to be the master table now instead of PO_VENDORS.
You will notice that the PARTY_NUMBER below is the Registry id in the R12
supplier screen.
Also, this party_id = 301934 will be referenced in the remainder set of tables.
Table HZ_PARTY_USG_ASSIGNMENTS
SELECT party_id ,party_usg_assignment_id,party_usage_code FROM hz_party_usg_assignments
WHERE party_id = 301934;
This table stores the Party Usages, for example, in this case it captures the fact that the given party_id is of type SUPPLIER.
Table
HZ_ORGANIZATION_PROFILES
SELECT * FROM hz_organization_profiles WHERE party_id = 301934
This table captures additional Supplier information, for example, credit
scoring details of Supplier or the Number of Employees working in Supplier
Organization.
Table IBY_EXTERNAL_PAYEES_ALL
SELECT * FROM iby_external_payees_all WHERE payee_party_id = 301934
This
table captures Payment related
details of the Supplier.
For example: -
1. How should the supplier's remittance advice be sent?
2. What is the default Payment method Code for this
supplier?
3. Who bears the bank charges when lets say SWIFT payment is
made?
This information can be setup at either the Supplier level or at Supplier Site
level.
Table AP_SUPPLIERS
SELECT vendor_id, vendor_name, segment1, enabled_flag FROM ap_suppliers
WHERE party_id = 301934
Alongside HZ_PARTIES, this is another master table that replaces the
PO_VENDORS table of 11i.
Instead of expanding the design of HZ_PARTIES, oracle decided to hold the
supplier specific attributes in AP_SUPPLIERS [fair enough!].
Table ZX_PARTY_TAX_PROFILE
SELECT party_type_code, party_tax_profile_id FROM zx_party_tax_profile
WHERE party_id = 301934
The taxation related details like Tax Codes, and Tax Accounts etc have been
moved from AP into ZX.
ZX is the name of a new Application "E-Business Tax".
Effectively this application is the Tax repository/Taxation Engine for
e-Business Suite starting from R12.
Effectively this also means that our good old AP_TAX_CODES_ALL is no longer the
master table for Taxes.
Now we have a new tax rate table, i.e. ZX_RATES_B.
ZX_ACCOUNTS is another table that has been introduced to capture accounting
setup related to Tax Codes.
Database View PO_VENDORS
select vendor_name, segment1, party_number from po_vendors WHERE party_id
= 301934
PO_VENDORS is a view in R12, that joins AP_SUPPLIERS & HZ_PARTIES.
Wait for concurrent request using fnd_concurrent.wait_for_request
Most of the times while submitting concurrent request one has to wait for its completion to perform sequence of steps. This can be achieved through fnd_concurrent.wait_for_request in oracle apps. It returns the status of the previously submitted concurrent program upon interval set.
This is a conjunction to the SUBMIT_REQUEST. Follow ARTICLE on submitting concurrent program and use below call upon completed. There are some parameter that has to be declared.
lb_complete BOOLEAN;
lc_phase VARCHAR2 (100);
lc_status VARCHAR2 (100);
lc_dev_phase VARCHAR2 (100);
lc_dev_status VARCHAR2 (100);
lc_message VARCHAR2 (100);
ln_request_id is return variable for concurrent_request_id from above article. If ln_request_id > 0 (means request submitted successfully) then wait_for_request.
Arguments (input)
request_id - Request ID to wait on
interval - time b/w checks. Number of seconds to sleep (default 60 seconds)
max_wait - Max amount of time to wait (in seconds) for request's completion
Arguments (output)
User version of phase and status
Developer version of phase and status
Completion text if any
phase - Request phase ( from meaning in fnd_lookups )
status - Request status( for display purposes )
dev_phase - Request phase as a constant string so that it can be used for comparisons
dev_status - Request status as a constatnt string
message - Completion message if request has completed
LOOP
l_req_return_status :=
fnd_concurrent.wait_for_request (request_id => to_number(rec_requests.request_id)
,INTERVAL => 2
,max_wait => 30
,phase => lc_phase
,STATUS => lc_status
,dev_phase => lc_dev_phase
,dev_status => lc_dev_status
,message => lc_message
);
EXIT
WHEN UPPER (lc_phase) = 'COMPLETED' OR UPPER (lc_status) IN ('CANCELLED', 'ERROR', 'TERMINATED');
end loop;
A few questions come to mind when we think about Multi Org in R12. The best way to analyse those questions is by opening package MO_GLOBAL. How is CLIENT_INFO being replaced in R12?
Let’s take an example.
In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info"But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL select * from all_policies where object_name='PO_HEADERS'
e. The effect of this policy is that, whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)
Also see **** below, latter
Does this mean, if I create a new custom table, I will have to apply RLS [Row Level Security] against Custom table too?
Yes indeed, if it contains data partitioned by ORG_ID. All you need to do in such case is to assign package function MO_GLOBAL.ORG_SECURITY to that table/synonym/view.
Will the Multi Org Row Level security be applied against the table or the synonym or the view?
In theory, RLS can be applied against any of the above objects. However in practice, you will apply RLS against Objects in APPS Schema. This means, you will most probably apply RLS on Synonyms. Basically, the Multi Org Views are now replaced by RLS Secured Synonyms. Hence no code change is required where the pre-R12 Multi-Org secured view was being accessed. The responsibility of securing data as per ORG_ID now lies with RLS [also known as VPD - Virtual Private Database].
I have made changes to my Multi Org Security Profile, by attaching a new Org Hierarchy. Do I need to run any process?
Just like we do in HRMS, it is advised that any changes to Security Profiles must be followed by running "Security List Maintenance"What is MO_GLOBAL.INIT
Purpose of mo_global.init :-
It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used.
If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmpWhen & from where is mo_global.init called ?
This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZEIs mo_glob_org_access_tmp table a global temporary table?
Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile]What is the purpose of MO_GLOBAL.ORG_SECURITY?
The purpose of Row-Level-Security is to hide certain data [based on some conditions]. RLS does so by appending a where clause to the secured object.
Let’s take an example.
In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info"But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL select * from all_policies where object_name='PO_HEADERS'
e. The effect of this policy is that, whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)
Also see **** below, latter
Does this mean, if I create a new custom table, I will have to apply RLS [Row Level Security] against Custom table too?
Yes indeed, if it contains data partitioned by ORG_ID. All you need to do in such case is to assign package function MO_GLOBAL.ORG_SECURITY to that table/synonym/view.
Will the Multi Org Row Level security be applied against the table or the synonym or the view?
In theory, RLS can be applied against any of the above objects. However in practice, you will apply RLS against Objects in APPS Schema. This means, you will most probably apply RLS on Synonyms. Basically, the Multi Org Views are now replaced by RLS Secured Synonyms. Hence no code change is required where the pre-R12 Multi-Org secured view was being accessed. The responsibility of securing data as per ORG_ID now lies with RLS [also known as VPD - Virtual Private Database].
I have made changes to my Multi Org Security Profile, by attaching a new Org Hierarchy. Do I need to run any process?
Just like we do in HRMS, it is advised that any changes to Security Profiles must be followed by running "Security List Maintenance"What is MO_GLOBAL.INIT
Purpose of mo_global.init :-
It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used.
If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmpWhen & from where is mo_global.init called ?
This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZEIs mo_glob_org_access_tmp table a global temporary table?
Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile]What is the purpose of MO_GLOBAL.ORG_SECURITY?
The purpose of Row-Level-Security is to hide certain data [based on some conditions]. RLS does so by appending a where clause to the secured object.
End User Step 2:
You can double check the created Supplier, which has Supplier Number 20186.
This supplier number comes from a table named AP_SUPPLIERS.
You can double check the created Supplier, which has Supplier Number 20186.
This supplier number comes from a table named AP_SUPPLIERS.
The registry id that you see is the Party_number field
from hz_parties [TCA Party Table]
Now, lets have a look at the list of tables impacted by creating the above Supplier record.
I am not saying that inserting into below listed tables is the way to create Suppliers in R12 TCA Model [Use API's for that].
This article is purely for your understanding of the new data model for Suppliers in R12 TCA.
Of course this will also be helpful to you when developing reports in R12.
Table HZ_PARTIES
SELECT * FROM hz_parties WHERE party_name= 'Go4Gold' ;
This happens to be the master table now instead of PO_VENDORS.
You will notice that the PARTY_NUMBER below is the Registry id in the R12 supplier screen.
Also, this party_id = 301934 will be referenced in the remainder set of tables.
Table HZ_PARTY_USG_ASSIGNMENTS
SELECT party_id ,party_usg_assignment_id,party_usage_code FROM hz_party_usg_assignments
WHERE party_id = 301934;
This table stores the Party Usages, for example, in this case it captures the fact that the given party_id is of type SUPPLIER.
Table HZ_ORGANIZATION_PROFILES
SELECT * FROM hz_organization_profiles WHERE party_id = 301934
This table captures additional Supplier information, for example, credit scoring details of Supplier or the Number of Employees working in Supplier Organization.
Table IBY_EXTERNAL_PAYEES_ALL
SELECT * FROM iby_external_payees_all WHERE payee_party_id = 301934
SELECT * FROM iby_external_payees_all WHERE payee_party_id = 301934
This
table captures Payment related
details of the Supplier.
For example: -
1. How should the supplier's remittance advice be sent?
2. What is the default Payment method Code for this supplier?
3. Who bears the bank charges when lets say SWIFT payment is made?
This information can be setup at either the Supplier level or at Supplier Site level.
Table AP_SUPPLIERS
SELECT vendor_id, vendor_name, segment1, enabled_flag FROM ap_suppliers WHERE party_id = 301934
Alongside HZ_PARTIES, this is another master table that replaces the PO_VENDORS table of 11i.
Instead of expanding the design of HZ_PARTIES, oracle decided to hold the supplier specific attributes in AP_SUPPLIERS [fair enough!].
For example: -
1. How should the supplier's remittance advice be sent?
2. What is the default Payment method Code for this supplier?
3. Who bears the bank charges when lets say SWIFT payment is made?
This information can be setup at either the Supplier level or at Supplier Site level.
Table AP_SUPPLIERS
SELECT vendor_id, vendor_name, segment1, enabled_flag FROM ap_suppliers WHERE party_id = 301934
Alongside HZ_PARTIES, this is another master table that replaces the PO_VENDORS table of 11i.
Instead of expanding the design of HZ_PARTIES, oracle decided to hold the supplier specific attributes in AP_SUPPLIERS [fair enough!].
Table ZX_PARTY_TAX_PROFILE
SELECT party_type_code, party_tax_profile_id FROM zx_party_tax_profile WHERE party_id = 301934
The taxation related details like Tax Codes, and Tax Accounts etc have been moved from AP into ZX.
ZX is the name of a new Application "E-Business Tax".
Effectively this application is the Tax repository/Taxation Engine for
e-Business Suite starting from R12.
Effectively this also means that our good old AP_TAX_CODES_ALL is no longer the master table for Taxes.
Now we have a new tax rate table, i.e. ZX_RATES_B.
ZX_ACCOUNTS is another table that has been introduced to capture accounting setup related to Tax Codes.
Database View PO_VENDORS
select vendor_name, segment1, party_number from po_vendors WHERE party_id = 301934
PO_VENDORS is a view in R12, that joins AP_SUPPLIERS & HZ_PARTIES.
Effectively this also means that our good old AP_TAX_CODES_ALL is no longer the master table for Taxes.
Now we have a new tax rate table, i.e. ZX_RATES_B.
ZX_ACCOUNTS is another table that has been introduced to capture accounting setup related to Tax Codes.
Database View PO_VENDORS
select vendor_name, segment1, party_number from po_vendors WHERE party_id = 301934
PO_VENDORS is a view in R12, that joins AP_SUPPLIERS & HZ_PARTIES.
Wait for concurrent request using fnd_concurrent.wait_for_request
Most of the times while submitting concurrent request one has to wait for its completion to perform sequence of steps. This can be achieved through fnd_concurrent.wait_for_request in oracle apps. It returns the status of the previously submitted concurrent program upon interval set.
This is a conjunction to the SUBMIT_REQUEST. Follow ARTICLE on submitting concurrent program and use below call upon completed. There are some parameter that has to be declared.
lb_complete BOOLEAN;
lc_phase VARCHAR2 (100);
lc_status VARCHAR2 (100);
lc_dev_phase VARCHAR2 (100);
lc_dev_status VARCHAR2 (100);
lc_message VARCHAR2 (100);
ln_request_id is return variable for concurrent_request_id from above article. If ln_request_id > 0 (means request submitted successfully) then wait_for_request.
Arguments (input)
request_id - Request ID to wait on
interval - time b/w checks. Number of seconds to sleep (default 60 seconds)
max_wait - Max amount of time to wait (in seconds) for request's completion
Arguments (output)
User version of phase and status
Developer version of phase and status
Completion text if any
phase - Request phase ( from meaning in fnd_lookups )
status - Request status( for display purposes )
dev_phase - Request phase as a constant string so that it can be used for comparisons
dev_status - Request status as a constatnt string
message - Completion message if request has completed
LOOP
l_req_return_status :=
fnd_concurrent.wait_for_request (request_id => to_number(rec_requests.request_id)
,INTERVAL => 2
,max_wait => 30
,phase => lc_phase
,STATUS => lc_status
,dev_phase => lc_dev_phase
,dev_status => lc_dev_status
,message => lc_message
);
EXIT
WHEN UPPER (lc_phase) = 'COMPLETED' OR UPPER (lc_status) IN ('CANCELLED', 'ERROR', 'TERMINATED');
end loop;
Most of the times while submitting concurrent request one has to wait for its completion to perform sequence of steps. This can be achieved through fnd_concurrent.wait_for_request in oracle apps. It returns the status of the previously submitted concurrent program upon interval set.
This is a conjunction to the SUBMIT_REQUEST. Follow ARTICLE on submitting concurrent program and use below call upon completed. There are some parameter that has to be declared.
lb_complete BOOLEAN;
lc_phase VARCHAR2 (100);
lc_status VARCHAR2 (100);
lc_dev_phase VARCHAR2 (100);
lc_dev_status VARCHAR2 (100);
lc_message VARCHAR2 (100);
ln_request_id is return variable for concurrent_request_id from above article. If ln_request_id > 0 (means request submitted successfully) then wait_for_request.
Arguments (input)
request_id - Request ID to wait on
interval - time b/w checks. Number of seconds to sleep (default 60 seconds)
max_wait - Max amount of time to wait (in seconds) for request's completion
Arguments (output)
User version of phase and status
Developer version of phase and status
Completion text if any
phase - Request phase ( from meaning in fnd_lookups )
status - Request status( for display purposes )
dev_phase - Request phase as a constant string so that it can be used for comparisons
dev_status - Request status as a constatnt string
message - Completion message if request has completed
LOOP
l_req_return_status :=
fnd_concurrent.wait_for_request (request_id => to_number(rec_requests.request_id)
,INTERVAL => 2
,max_wait => 30
,phase => lc_phase
,STATUS => lc_status
,dev_phase => lc_dev_phase
,dev_status => lc_dev_status
,message => lc_message
);
EXIT
WHEN UPPER (lc_phase) = 'COMPLETED' OR UPPER (lc_status) IN ('CANCELLED', 'ERROR', 'TERMINATED');
end loop;
No comments:
Post a Comment