I wonder whether this is because the UTL_HTTP package doesn’t immediately work with https:// addresses, and you are perhaps using https in your IFS URL?Here’s an article that seems to do a good job (i.e. I haven’t used it myself) of explaining some of the challenges and how to get UTL_HTTP to access https addresses:https://oracle-base.com/articles/misc/utl_http-and-ssl Nick
Hi Antony - good to see you at WoCo.We have an Apps9 interface to and from FlexNet MES. The interface was originally deployed for Apps7 but remained solid when we upgraded to Apps9 with no real changes needed. I will also note that we are in the process of looking to reimplement/update FlexNet so some changes may be on the horizon.Nick
I’m not sure if you truly mean single sign-on SSO (i.e. you do not need to log in to IFS when you open it) or if you mean that you want to use your network/Active Directory account credentials to log in to IFS (which is what we have done for Apps9 and Apps10). The first scenario is a possible security risk because someone can open IFS on your PC without entering any credentials if you leave your PC unlocked. The second scenario would prevent that because your network/AD credentials would need to be used to log in to IFS. Of course, if you left your PC unlocked and IFS open then nothing can save you...We found that the technical documentation that IFS provided for implementing network/AD authentication for both Apps9 and Apps10 was mostly complete and accurate. In our case we are using Microsoft Azure AD as the authentication source and it is working well for us so far.I would also suggest reposting this question in the ‘Technology’ group on here. I suspect most technical community
@Helen Smith Pawel’s answer above is likely best for your situation, but you could also use the “Security per User” report. This will also show all of the permission sets granted directly and indirectly to a user, but it will also include all of the objects granted to each of those permission sets.It looks like the extra information will probably be too much for your requirement here, but it might help others who are trying to get the full list of permission sets so they can then identify what objects are actually granted.Nick
For a full list of last logins in Apps9 and Apps10 you can simply use the following… I don’t believe any specific auditing needs to be turned on to enable this:select username, last_login from SYS.DBA_USERS where account_status='OPEN' order by last_login desc;However, based on the Author’s later reply the above query will not track Azure AD authenticated account logins.Nick
durette wrote: I don’t recommend everyday end users querying the raw tables, since this works around all row-level security and exposes the possibility of manipulating the data outside of the business logic, but this method does have its place for an IT user. Totally agree.
> SELECT * FROM transaction_sys_local_tab; -- Background Jobs> SELECT * FROM transaction_sys_status_tab; -- Background Job status linesI would suggest not using the above 2 Tables as a point of reference. IFS screens (almost?) always pull from Views rather than Tables, and using the Debug console I can see that Background Jobs are pulled from the DEFERRED_JOB view in Apps9. There is a matching DEFERRED_JOB_STATUS view too.
I agree with Pete that the Debug console is the best starting point, so something like Background Jobs will show as coming from the appowner DEFERRED_JOBS view, but I think the difficulty with some of the Solution Manager area screens is that they may be using SYS owned objects, e.g. SYS.DBA_SCHEDULER_JOBS. I suspect these are the ones that don’t tend to show even in the Debug console.
An important clarification about CTU licenses is that they can also be required in addition to a Full Use license. For example, a user who uses multiple areas of IFS as well as something like Shop Floor Workbench or who is a Timeclock user, will consume both a Full Use license and a CTU license.The key is to recognize that a Full Use license doesn’t by itself allow for use of CTU functions.Nick
For my 2c, I think that for most people running it from inside IFS makes most sense - it is just simpler to execute.In much early versions I’m not sure I trusted it so much, but for recent versions I’m comfortable with the interface approach for ‘everyday’ work.Like you I’ve also not seen any differences between doing it from the GUI or doing it programmatically in the DB. Since most changes we make (apart from deployments) are in the interface itself, that seems to be the path of least resistance.Nick
I think it is worth reiterating that for an LTU the permission set needs to be pretty much set in stone before sending to IFS/implementing as an LTU. Adjusting an agreed-upon LTU permission set at a later time will invalidate the license and will require going through the certification process again.As I understand it (maybe someone from IFS can confirm?) the LTU must also be fairly limited in scope. I’m not sure how IFS quantifies what is really ‘limited' in this sense, but for example I don’t believe that you can create a permission set with access to the majority of your system and try to implement that as an LTU.Nick
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.