Lum IV custom role problem
Has anyone implemented a custom role generated in Banner and fed into luminis within the Lum IV portal?
According to the docs, it looks simple. We've set up the Banner side easily, and I can see a customrole coming across in our LMG data log, ldi_event_data.log. It appears though, that Luminis is ignoring this. I do not see the custom role being added to the persons ldap record. However, other attributes of the same event do get processed (like a name change), so events in general are working.
I have set the pds.roles.external to include the custom role value to match what I see in the xml event. Are there any other settings that I missed on the Luminis side?
I've set the LMG and IMQ broker to debug modes, but I am not seeing any clear errors. I have an open ticket with SCT, so I'll post back if they provide a solution.
Hack Your Knowledge
Recent blog posts
- Updated to 4.1.22 - Complications
- Time Estimate for Luminis Platform IV Upgrade
- Luminis IV Memory Configuration
- CPIP Novice Looking for HELP!
- Targeted Announcement Permissions and Grants
- Associated Press OSTN Video News Portlet/Channel
- EAS credentials not the same as luminis credentials
- Lumiins start up issues
- Messaging Server Configuration
- User Attributes from Banner
Developer Links
Poll
Syndicate
Create new access group from portal admin
Not sure how it works in LP IV, but in LPIII, we had to use the luminis admin gui to create a new access group bearing the same name as the custom role. Take a look at http://www.lumdev.net/node/909 for additional info.
access group. Yep that was
access group. Yep that was probably it. Unfortunately now my events aren't working:(
mbtool list subscriptions -dest=com_sct_ldi_sis_Sync shows it as inactive, and I can't for the life of me get it active again.
Sometimes I really get annoyed with LMB heh.
Are the destinations enabled?
Did you verify that the destinations are enabled? sometimes these get turned off when hotfixes or patches are applied.
This should give you a list of enabled messaging destinations; check to make sure that messaging.datapipeline.client.cp$cpincoming.enabled is set to true.
Alice Kim
configman -g messaging.datapipeline.* | grep enabled
Yes, thanks. I did check that, and it was still disabled despite several stopcp/startcp's. Then about 2 hours later it went active. Then about 2 more hours later, it went inactive again, although this time, the configman settings were false, so upon setting them back to true, a web server restart fixed the issue.
And our custom role is working fine now that we added a matching access group. Thanks.