diff --git a/perydAffilFwork.adoc b/perydAffilFwork.adoc index 10120de..4e53c8d 100644 --- a/perydAffilFwork.adoc +++ b/perydAffilFwork.adoc @@ -3,61 +3,63 @@ Pery Doan, 2 December 2022 I'm glad to know that we have some PeopleSoft developers on the call. I wasn't sure how this meeting was going to go, so I kind of prepared for doing a little bit more of a deep dive on how the affiliation process actually works, even though at SMU We've um gone with um, using some of the delivered functionality, but then also have some custom implementation that goes with it. -So I will start with just showing you guys, some diagrams of our environment. Do a little bit of a quick demo just to show you some screens, so that hopefully some of the more boring slides that come after that which are a lot to describe how the Affiliation Framework is intended to work in PeopleSoft, and how you would configure it. Um would make a little bit more sense to you guys, as we're going through it. Um also my main goal in kind of throwing this slides a bunch of slides in here. Um with, so that I can then share it with you guys afterwards, and you would have like sort of a a roadmap. Um, if you wanted to try doing a like a proof of concept um at your school, you would know where to start. It's not going to have everything in it, obviously, but I give you some references too at the end. Um to some of the technical documents you can. You can find out there. +So I will start with just showing you guys, some diagrams of our environment. Do a little bit of a quick demo just to show you some screens, so that hopefully some of the more boring slides that come after that which are a lot to describe how the Affiliation Framework is intended to work in PeopleSoft, and how you would configure it. Um would make a little bit more sense to you guys, as we're going through it. Um also my main goal in kind of throwing this slides a bunch of slides in here so that I can then share it with you guys afterwards, and you would have a roadmap. Um, if you wanted to try doing a like a proof of concept at your school, you would know where to start. It's not going to have everything in it, obviously, but I give you some references too at the end to some of the technical documents you can.find out there. -So just for you PeopleSoft folks. This is kind of our environment here. At some you we have CS HCM And Financials, +So just for you PeopleSoft folks. This our environment at SMU. We have CS, HCM, And Financials, image::images/mySmu.png['PeopleSoft Packages', width=700] -and we try to keep current with um updates and fixes on a quarterly basis, and we are an oracle shop on release one thousand 19.16 and we use canvas solutions as our portal, and we leverage unified navigation to pull our Hcmfs content into our CS home pages, and we do heavily use uh Gideon Taylor: Well, I say heavily, we we now have it across all of three environments, and we um are starting to become more and more dependent on that uh framework. +We try to keep current with updates and fixes on a quarterly basis, and we are an Oracle shop on release 19.16 and we use Campus Solutions as our portal, and we leverage unified navigation to pull our HCM and FS content into our CS home pages, and we do heavily use Gideon Taylor: Well, I say heavily, we now have it across all of our three environments, and we are starting to become more and more dependent on that framework. I just found this one diagram that I put together a while back, -just to show how we have like different sources around campus that enter data person data. +just to show how we have different sources around campus that enter person data. image::images/identityFlow.png['Person Data Sources', width=700] -The departments in blue. We have different applications as well, like slate and black bod that create Ids identity data in our People's cell system. So that's this column here, where we have this person model and we are using um the delivered service operations to sync our um fleet, split databases which you know we we split back in two thousand and fourteen, and use the subscriber only integration model, and we have um, you know, person basic sync and diversity sync, and all of this nice fun delivered um service operations enabled to do bidirectional syncing of our person data. And then um, we move on to the transaction data where we have employee.SMU: You synchronizing job data. It's just the one way integrationfor um, the workforce sync and position data. We also have user profiles getting synced, and that's not represented in this diagram, but for user. Profiles. +So that's the departments in blue. We have different applications as well, like Slate and Blackbaud that create identity data in our PeopleSoft system. So that's this column here, where we have this person model and we are using the delivered service operations to sync our split databases which we split back in 2014, using the subscriber only integration model, and we have person basic sync and diversity sync, and all of these nice, fun delivered service operations enabled to do bidirectional syncing of our person data. And then we move on to the transaction data where we have employee.smu synchronizing job data. It's just the one-way integration for the workforce sync and position data. We also have user profiles getting synced, and that's not represented in this diagram. -Our CS instance is our um authoritative data source. So it it sends everything to uh employee.Smu. And also our setup data is authoritative in an employee Dot Smu, and syncs over to our campus solutions. Instance. From there also you can see that we do have some external affiliation sources that we manage. So in in these two boxes we have our employees and students, and we do have some sponsored identities that we select here based on um instructor data. So when we don't have the authoritative, you know job data to tell us this is an adjunct. We use the um schedule of classes and the instructor visor table to figure out who's teaching, and then we go ahead and give them a sponsorship that we call instructor-sponsored access. +Our CS instance is our authoritative data source. So it it sends everything to uh employee.Smu. And also our setup data is authoritative in an employee.smu, and syncs over to our Campus Solutions instance. From there also you can see that we do have some external affiliation sources that we manage. So in these two boxes we have our employees and students, and we do have some sponsored identities that we select here based on instructor data. So when we don't have the authoritative job data to tell us this is an adjunct. We use the schedule of classes and the instructor/advisor table to figure out who's teaching, and then we go ahead and give them a sponsorship that we call instructor-sponsored access. -we have other sponsorships down here represented that go into this box here, which is our current custom, identity management type uh bolt-on that we created in PeopleSoft and campus solutions which i'll talk more about. But then the end result is that we have our service provisioning, and even just physical access uh kind of directed by the logic that is running here in this engine. +we have other sponsorships represented that go into the AMA, which is our current custom, identity management bolt-on that we created in PeopleSoft and Campus Solutions which i'll talk more about. But then the end result is that we have our service provisioning, and even just physical access directed by the logic that is running here in this engine. -So for our current state. we have PeopleSoft as our person registry. We have this custom uh account maintenance automation, AMA bolt-on that determines the person, affiliation and service eligibility. And then we have Tommy's power shell script, or maybe more than one script that actually performs the service provisioning, +So for our current state. we have PeopleSoft as our person registry. We have this custom uh Account Maintenance Automation, (AMA) bolt-on that determines the person, affiliation and service eligibility. And then we have Tommy's power shell scripts that actually performs the service provisioning. -What we did with our affiliation. Framework. Um project is sort of just replace -a piece of what AMA does, Which is this right here assigning what we call user types, and you will hear um me interchangeably use the term user type and affiliation. Um, throughout. +What we did with our Affiliation Framework project is replace a piece of what AMA does assigning what we call user types, and you will hear me interchangeably use the term user type and affiliation throughout. -In our in our future state as we are implementing um co-manage and grouper in midpoint. This is kind of Still, you know we're still in process of doing all of these things. One of the very first things and foundational things that we needed to do was, figure out. Well, how are we going to determine a person's affiliation? And we landed on trying to leverage the Affiliation Framework so that we can keep that logic and leverage all the work that we did with AMA Um to sort of transition into Affiliation Framework, to assign and remove our user types, and that makes it a little bit easier. Now, with our integration with kill, manage where we are, not only sending the bio demo data, but we're also attaching a bit of the affiliation data with those identities. We realize that that relationship data was sort of critical to have at the Ident in our new enterprise person registry. So that when we have somebody like we have a co-worker whose name is Eric macy. And there was a student who had that same name. And so it's just really a lot. it's very important in Higher Ed to be able to distinguish a student from a staff, for example, at the person registry level. So we are sending a few sort of affiliation related attributes to co-manage, and then, you know later, grouper is going to leverage co-manage for determining service. Eligibility assign and remove services, and, also, you know, reach back into people's soft itself, so it'll go back to employee. That's uh i'm sorry my smu and grab uh whatever information it requires for additional provisioning that perhaps wouldn't be in the co-manage registry. you know, moving to the Affiliation Framework, we took that opportunity to sort of revisit, and um broke out like our benefit, eligible employees, into more distinct affiliations. We also broke out the ones that we go ahead and select even before their effective date. So if somebody gets hired ahead of time right now Am. A will go ahead and assign these user types, and we can distinguish them really from people who are, you know, current versus future dated hires. So that kind of is a neat feature that I think we're gonna really like. We've also um been able to identify uh the non degree students, which is nice. And we broke out the active students into undergraduate and graduate to give us a little more granularity. At this point I wanted to show you just quickly couple of the pages. +In our in our future state as we are implementing COmanage and Grouper and midpoint. We're still in process of doing all of these things. One of the very first things and foundational things that we needed to do was figure out, Well, how are we going to determine a person's affiliation? And we landed on trying to leverage the Affiliation Framework so that we can keep that logic and leverage all the work that we did with AMA to transition into Affiliation Framework, to assign and remove our user types, and that makes it a little bit easier. Now, with our integration with COmanage where we are not only sending the bio demo data, but we're also attaching a bit of the affiliation data with those identities. -So our account maintenance automation I have, an Id that I want to show yobuild time. We're still using this as we're implementing our new. I am components allows us to. As you can see, it selects the type of person This is, and then assigned services, and we've gotten very accustomed to being able to see Well, where is that coming from. So I I built into this bolt on the ability for people to see why. This person is an adjunct faculty and a temporary staff. You can actually see that here, and I mean, I see here that they were terminated as a temp staff on twelve one. But this is a test environment, and I have not run. Am I? So? They still show as um active staff. But if I ran a for this person, they would lose that affiliation, and only retain their active temporary faculty. Um position. I can also see that this person is in the instructor Advisor Table. Um, and they are an adj. An instructor type of adjunct, and that they are attached to future classes. So if this person were a student, I would see, you know, student information here under these grids that kind of um. The AMA is using itself as the source data to make these decisions. So that has been very helpful, because when there are any questions about, Why did this person not get picked up? Why did this person you know this or that? I'm? I'm not bombarded with a million people asking me questions. They can just go here and see what that what that may be. +We realize that that relationship data was sort of critical to have in our new enterprise person registry. So that when we have a co-worker whose name is Eric Macy. And there was a student who had that same name. And so it's just really a lot. it's very important in Higher Ed to be able to distinguish a student from a staff, for example, at the person registry level. So we are sending a few sort of affiliation related attributes to COmanage, and then later, Grouper is going to leverage COmanage for determining service eligibility, assign and remove services, and also reach back into PeopleSoft itself, so it'll go back to employee in My SMU and grab whatever information it requires for additional provisioning that perhaps wouldn't be in the COmanage registry. Moving to the Affiliation Framework, we took that opportunity to sort of revisit, and broke out our benefit eligible employees, into more distinct affiliations. We also broke out the ones that we select even before their effective date. So if somebody gets hired ahead of time right now, we will go ahead and assign these user types, and we can distinguish them from people who are current versus future dated hires. So that kind of is a neat feature that I think we're gonna really like. We've been able to identify the non-degree students, which is nice. And we broke out the active students into undergraduate and graduate to give us a little more granularity. At this point I wanted to show you just quickly a couple of the pages. -So the reason I wanted to show you that is because in the Affiliation Framework I'm. Going to show you this person who -and i'm going to show you the delivered page. So this is what the delivered page would look like. It still shows me right that they're an adjunct that they're an instructor, temp staff, and a conversion former student, which is something that am, I does not pay attention to. So that's why this is kind of a new thing here. I can see that the affiliation is active, and I can click into the context fields, which is something. Um, that we're leveraging with the delivered framework to be able to say, Okay, what are some? You can define these, you know. You can tell it whatever record name you want and field name. We kind of piggybacked on that, and just are saying co-manage, because that's what we're using it for. For when we create our Json uh message over to co-manage, we are grabbing information from this table. And we're saying that this person for their adjunct faculty, affiliation has, you know, happens to be in the meadow School of the arts, and the department is news. The Cat Junks title is not going to be populated. Uh, we're not allowed to do that at the time, and then we have their uh primary affiliation, which is faculty and their manager. +So our Account Maintenance Automation I have, an ID that I want to show yobuild time. We're still using this as we're implementing our new IAM components allows us to. As you can see, it selects the type of person this is, and then assigned services, and we've gotten very accustomed to being able to see where is that coming from. So I built into this bolt-on the ability for people to see why. This person is an adjunct faculty and a temporary staff. You can actually see that here, and I mean, I see here that they were terminated as a temp staff on twelve one. But this is a test environment, and I have not run it recently. So they still show as um active staff. But if I ran ANA for this person, they would lose that affiliation, and only retain their active temporary faculty position. I can also see that this person is in the instructor Advisor Table. and they are an instructor type of adjunct, and that they are attached to future classes. So if this person were a student, I would see, you know, student information here under these grids that the AMA is using itself as the source data to make these decisions. So that has been very helpful, because when there are any questions about, Why did this person not get picked up? Why did this person you know this or that? I'm? I'm not bombarded with a million people asking me questions. They can just go here and see what that may be. -Those are the attributes that we're sending over to co-manage.This is all very helpful. But what I ended up doing is creating a custom page, which is this affiliation snapshot, which is very much modeled after what I did with AMA, so that at the top I can see. Okay, here's the active user types. Here might be any inactive ones, and these are really affiliations. We're just using the same terminology that users are used to seeing which is user type, and also because, you know, when you're talking about this affiliation, which is more sort of like a high level affiliation. There's the affiliation codes, and then there's this affiliation and primary relation it can. There's a lot of affiliation, and it can get confusing. So we've decided to try to call these affiliation codes user types, and then um, we have the revelation, and I can see right away. I don't have to click and drill in to see what those attributes are for that particular code. And I also have our data source details um included here, so that that is, uh one of the benefits of us having done it. Um, you know, with a bit of a custom component to this process, and then I can also access affiliation, history. Of course I haven't. Nothing happened to this person, but you would be able to see over time things that are activated or um inactivated, as as time goes on, and I can also see details about our co-manage Api, whether it has gone uh successfully. Or it's waiting to be processed, or you know, whatever it may be. Also as as part of our co-manage um integration. We have a put that sends information from affiliation, framework, and our person model over to come, manage, and then we receive this post which um updates the external system, identifiers and PeopleSoft, and we haven't run it in this test environment. But we would see here what those external ids would be, so that we can understand and and see within PeopleSoft what that enterprise Id is, and what's the other one, Tommy? So just a bit of background on that When PeopleSoft sends. The put message to Co. Manage will respond back with identifiers that co-manage generates and so we're generate currently we're generating two. One is a net Id or a network Id and the other is the enterprise Id uh so a lot we could say about that. But that's uh that's the idea. So the other thing I wanted to show you here, while while I'm here is um. +*- at the 21 minute mark -* -One other neat feature of the Affiliation Framework delivered application is that in any component where there are bio demo data type information about, you know, throughout people's soft. There is an integrated icon which is this little house which is the appellation display. So, no matter where, like I, I was looking at um like, I think, academic program information on on a student, and it had this a little affiliation box. So you can actually see what other affiliations that person might have right right there at your fingertips. That's pretty cool. +So the reason I wanted to show you that is because in the Affiliation Framework I'm. Going to show you this person and i'm going to show you the delivered page. So this is what the delivered page would look like. It still shows me right that they're an adjunct that they're an instructor, temp staff, and a conversion former student, which is something that am, I does not pay attention to. So that's why this is kind of a new thing here. I can see that the affiliation is active, and I can click into the context fields, which is something. Um, that we're leveraging with the delivered framework to be able to say, Okay, what are some? You can define these, you know. You can tell it whatever record name you want and field name. We kind of piggybacked on that, and just are saying COmanage, because that's what we're using it for. For when we create our Json uh message over to COmanage, we are grabbing information from this table. And we're saying that this person for their adjunct faculty, affiliation has, you know, happens to be in the meadow School of the arts, and the department is news. The Cat Junks title is not going to be populated. Uh, we're not allowed to do that at the time, and then we have their uh primary affiliation, which is faculty and their manager. + +Those are the attributes that we're sending over to COmanage.This is all very helpful. But what I ended up doing is creating a custom page, which is this affiliation snapshot, which is very much modeled after what I did with AMA, so that at the top I can see. Okay, here's the active user types. Here might be any inactive ones, and these are really affiliations. We're just using the same terminology that users are used to seeing which is user type, and also because, you know, when you're talking about this affiliation, which is more sort of like a high level affiliation. There's the affiliation codes, and then there's this affiliation and primary relation it can. There's a lot of affiliation, and it can get confusing. So we've decided to try to call these affiliation codes user types, and then um, we have the revelation, and I can see right away. I don't have to click and drill in to see what those attributes are for that particular code. And I also have our data source details um included here, so that that is, uh one of the benefits of us having done it. Um, you know, with a bit of a custom component to this process, and then I can also access affiliation, history. Of course I haven't. Nothing happened to this person, but you would be able to see over time things that are activated or um inactivated, as as time goes on, and I can also see details about our COmanage Api, whether it has gone uh successfully. Or it's waiting to be processed, or you know, whatever it may be. Also as as part of our COmanage um integration. We have a put that sends information from affiliation, framework, and our person model over to come, manage, and then we receive this post which um updates the external system, identifiers and PeopleSoft, and we haven't run it in this test environment. But we would see here what those external IDs would be, so that we can understand and and see within PeopleSoft what that enterprise ID is, and what's the other one, Tommy? So just a bit of background on that When PeopleSoft sends. The put message to Co. Manage will respond back with identifiers that COmanage generates and so we're generate currently we're generating two. One is a net ID or a network ID and the other is the enterprise ID uh so a lot we could say about that. But that's uh that's the idea. So the other thing I wanted to show you here, while while I'm here is um. + +One other neat feature of the Affiliation Framework delivered application is that in any component where there are bio demo data type information about, you know, throughout PeopleSoft. There is an integrated icon which is this little house which is the appellation display. So, no matter where, like I, I was looking at um like, I think, academic program information on on a student, and it had this a little affiliation box. So you can actually see what other affiliations that person might have right right there at your fingertips. That's pretty cool. So now like to jump into the Affiliation Framework. You know there's some pretty basic things. We know that it tracks them a relationship with the institutions um over time, and it was delivered as part of the nineo feature pack one. This was back in two thousand and nine. And uh, it is a more robust method of tracking affiliations than the relationship with institution component within campus solutions. I don't know if you guys are familiar with it. We used to use that as well, and I thought it was going to replace it. But as I was looking at people's books recently found out that it's not. It didn't replace it. It's just more of a robust method of of tracking affiliations. This framework will allow you to update those manually and batch or triggered by affiliation events. -And then we already talked about the little icon. So it is part of the constituent web services and campus solutions. Not sure if you guys are familiar with it, but it is designed. The Cws is designed to allow and facilitate integration of people, self systems with external systems, and it also is heavily used with interaction. Hub and the external search match functionality, and of course, oracle identity manager delivered a connector into CS. Which increase integrates with affiliation, framework, and um constituent web services. I've heard not very good things about that, but that is what it is. We also know that Um, the constituent transaction management framework, which is what we use for loading our slate applications into PeopleSoft. There's the data update rules. The affiliation override dependencies for that interface. So that's another reason why we wanted to. Um, you know, use the Affiliation Framework, and when we went live with a slate. +And then we already talked about the little icon. So it is part of the constituent web services and campus solutions. Not sure if you guys are familiar with it, but it is designed. The Cws is designed to allow and facilitate integration of people, self systems with external systems, and it also is heavily used with interaction. Hub and the external search match functionality, and of course, Oracle identity manager delivered a connector into CS. Which increase integrates with affiliation, framework, and um constituent web services. I've heard not very good things about that, but that is what it is. We also know that Um, the constituent transaction management framework, which is what we use for loading our slate applications into PeopleSoft. There's the data update rules. The affiliation override dependencies for that interface. So that's another reason why we wanted to. Um, you know, use the Affiliation Framework, and when we went live with a slate. I don't remember when it was, but it was a while back we tried to implement Affiliation Framework and had a lot of hurdles. So we ended up just so that we could meet this need delivering. I just created like a SQL script that the Dba's had on a cron job that would run every night to identify current employees, former employees, current students, and former students, so that when new apps came into the system it would check and see, because they did not want -those applications to update any bio demo data for existing current employees, for example, or existing current students and things like that. So that's where that comes in currently. We've gone live with Affiliation Framework like two weeks ago when it went Live any discrepancies, you know, do doing, reporting. We can um use it to continue our co-manage integration efforts and things like that. But I thought it would be interesting to show you guys, some of the counts that we have with our current um affiliations. And I, broke out the instructor, one, because that one is not dependent on job data, obviously right. So So the ones that have, for example, adjunct faculty. There's three hundred and thirty-eight. But as you can see here, Um, we have e instructor assigned to six hundred and sixty-eight that are set up as instructor type adjunct in the instructor visor table, and that is because we do have an issue with getting those higher forms in a timely fashion and things like that. So the instructor. Affiliation code is intended to be sort of a high level. We don't want to say that you are an adjunct, because you can be a teaching assistant, or a Gsi, or graduate student structure, full time, faculty, or whatever. And currently, unfortunately, in our PeopleSoft system. These instructor types are not maintained, So there's not a high degree of confidence, and using those as our as our source to say, Yes, you are now assigned right. We know of instances where, for example, we have full time faculty that come in, so they're in this table as full time faculty. They retire. They come back as adjuncts, and nobody updates their role to adjunct again. So we're moving in other projects to try to improve that data quality, and we have made a lot of progress in trying to sync it up with what job data says and things like that. But we're still not at one hundred percent confidence in those designations. But we're moving in the right direction, I feel, and I think and hope that by the time we're ready to go live with our new Im solution that things will be a lot more timely and accurate in our in our data. +those applications to update any bio demo data for existing current employees, for example, or existing current students and things like that. So that's where that comes in currently. We've gone live with Affiliation Framework like two weeks ago when it went Live any discrepancies, you know, do doing, reporting. We can um use it to continue our COmanage integration efforts and things like that. But I thought it would be interesting to show you guys, some of the counts that we have with our current um affiliations. And I, broke out the instructor, one, because that one is not dependent on job data, obviously right. So So the ones that have, for example, adjunct faculty. There's three hundred and thirty-eight. But as you can see here, Um, we have e instructor assigned to six hundred and sixty-eight that are set up as instructor type adjunct in the instructor visor table, and that is because we do have an issue with getting those higher forms in a timely fashion and things like that. So the instructor. Affiliation code is intended to be sort of a high level. We don't want to say that you are an adjunct, because you can be a teaching assistant, or a Gsi, or graduate student structure, full time, faculty, or whatever. And currently, unfortunately, in our PeopleSoft system. These instructor types are not maintained, So there's not a high degree of confidence, and using those as our as our source to say, Yes, you are now assigned right. We know of instances where, for example, we have full time faculty that come in, so they're in this table as full time faculty. They retire. They come back as adjuncts, and nobody updates their role to adjunct again. So we're moving in other projects to try to improve that data quality, and we have made a lot of progress in trying to sync it up with what job data says and things like that. But we're still not at one hundred percent confidence in those designations. But we're moving in the right direction, I feel, and I think and hope that by the time we're ready to go live with our new Im solution that things will be a lot more timely and accurate in our in our data. So how does the delivered Affiliation Framework process works. A lot of what you're gonna see are things that I took from the Campus Solutions Affiliation Developer Guide. I just copied this high level diagram of how it works where you have constituent information that's changing the system. For example, Admissions matriculates a student or HR terminates an employee, that's a change; or some self service utility that a student uses to change their address. -Then you have Integration Broker messages that are published. And the way that oracle developed. This process was really thinking, and and it really was developed forures I mean the batch concept came later on, and kind of was kind of forced into it, but it was intended, so that you know any time you have a change in the system, it would trigger a message which would then trigger the Affiliation Framework process to process that message and then assign or remove affiliations according to that data. +Then you have Integration Broker messages that are published. And the way that Oracle developed. This process was really thinking, and and it really was developed forures I mean the batch concept came later on, and kind of was kind of forced into it, but it was intended, so that you know any time you have a change in the system, it would trigger a message which would then trigger the Affiliation Framework process to process that message and then assign or remove affiliations according to that data. -If you want to talk to an external system like Om. Or something and the uh Affiliation Developer guide does not really talk in great depth about the constituent web services. They refer you to the constituent Web Services developer, guide for further information. If you're interested in and knowing more about that I to send you. Of course we're not doing that. We created a custom web service that leverages Affiliation Framework. Data.And since JSON message over to Co-manage um that I that I shared earlier our put message. +If you want to talk to an external system like Om. Or something and the uh Affiliation Developer guide does not really talk in great depth about the constituent web services. They refer you to the constituent Web Services developer, guide for further information. If you're interested in and knowing more about that I to send you. Of course we're not doing that. We created a custom web service that leverages Affiliation Framework. Data.And since JSON message over to COmanage um that I that I shared earlier our put message. now i'm gonna talk through these steps kind of like in a little bit more detail. So the constituent information is changing in the system via different ways. Right? So the the relevance of of outlining. This is because you you've got to think about. If you're If you want to go with trigger based transactions, then you pretty much have to um update everywhere in the system where you're interested in having that trigger sent, you have to modify those components if they are not already sending some sort of message right? So like we wouldn't need to necessarily modify the job component, because it's already triggering work for sync into campus solutions so that could be leveraged as something that would then trigger the Affiliation Framework. But if I wanted to change somebody's academic program or um, you know, admissions matriculate somebody, or whatever it may be, those are things that don't trigger anything today, and camp solutions. So we would have to modify those components to have some sort of message triggerthe uh, And so that that's what these two like, whether still service or administrator makes online update. The other thing i s like batch updates. So if we have a program, for example, like I'm: sure pretty sure admissions, You know, matriculates people in bachelor. I'm gonna go one by one. So those batch program updates umhave to be. You have to use this specific pattern to trigger the appropriate messages so that those triggers happen. So. Integration, That's the second step. The Integration broker message is published, and so that's the code that's needed, and i'm sorry if i'm not being very good at this I put this presentation together yesterday, and I I haven't practiced it at all. So please forgive me upon all over the place. But this um just explain basically what I just said about the component triggers. You can also like, if you have a custom app engine program that makes updates or even delivered one. You can actually have a call, you know, and and trigger the messages, and then for the cobalt and sqrs. You would use this um delivered table, and that you'll publish programs to the message into the table If the Affiliation Framework processes the message. And this is where This is cool. I I like the fact that in affiliation firmware. There's really only three tables that are updated. You have your person affiliation. And then the context data that I showed you guys like there's one that has the data fields because it's um configurable. You can tell it what record and what field to use. Then it it has to have a way to track that, And then there's the value table. So it's. It's pretty simplistic. The thing that's not very simplistic is how they design this thing to work. And this is a diagram that um we. We hired a consultant to help us with this. He's very, very smart and very good with um at packages, so he really understood, after -doing our proof of concept how this thing works, and I have the example of a custom trigger event which is really what is described in the Developer guide is This is what you will see on how to, you know, set up a proof of concept and what it does, is it? Will you know you have to? I'll show you the steps, but you you create your own service operation, and then it that's what triggers through the handler, the Affiliation Framework. There's a custom adapter that's called, and then it returns to the Affiliation Framework. Then it does the implementation classthen it returns the information framework, and then it finally gets an answer whether it's affiliated or not. And this is done for one Id at a time right, because the way that this was designed was relief to work for triggers. So you're only processing one message at a time. Then um for the delivered trigger example. We have that workforce sync where you have an existing service operation that you can modify. You can go in there and add the handler to it,and then it will, of course, as soon as it triggers it will go ahead and trigger your Affiliation Framework. +doing our proof of concept how this thing works, and I have the example of a custom trigger event which is really what is described in the Developer guide is This is what you will see on how to, you know, set up a proof of concept and what it does, is it? Will you know you have to? I'll show you the steps, but you you create your own service operation, and then it that's what triggers through the handler, the Affiliation Framework. There's a custom adapter that's called, and then it returns to the Affiliation Framework. Then it does the implementation classthen it returns the information framework, and then it finally gets an answer whether it's affiliated or not. And this is done for one ID at a time right, because the way that this was designed was relief to work for triggers. So you're only processing one message at a time. Then um for the delivered trigger example. We have that workforce sync where you have an existing service operation that you can modify. You can go in there and add the handler to it,and then it will, of course, as soon as it triggers it will go ahead and trigger your Affiliation Framework. -The batch process is run through Process scheduler, of course, but it um. It calls that message handler directly, so it does not generate Ib. Messages so you wouldn't see those an integration broker or anything like that, however, because it is working with just the way that this is designed, it's going to process one Id at a time instead of doing set-based processing. It's an app engine that is very inefficient, and it leverages the pop select query um forget what that framework is called, but it does leverage that, and It proved very inefficient for us. So that's one of the reasons why we are not using this delivered process. I know that there are two schools out there at least. Um. +The batch process is run through Process scheduler, of course, but it um. It calls that message handler directly, so it does not generate Ib. Messages so you wouldn't see those an integration broker or anything like that, however, because it is working with just the way that this is designed, it's going to process one ID at a time instead of doing set-based processing. It's an app engine that is very inefficient, and it leverages the pop select query um forget what that framework is called, but it does leverage that, and It proved very inefficient for us. So that's one of the reasons why we are not using this delivered process. I know that there are two schools out there at least. Um. A long time ago I I found two presentations, one from two thousand and fifteen, one from two thousand and eighteen where um you know those schools are running it, and they're running the deliver process. So I think that it can be done. It just was not something that we did we deemed feasible for our institution. All right. So then, um step four is, you know, the affiliations getting assigned or removed. And I just have this to show you an example of a person with affiliations. And then here's the person table. You can see here that the start date is a key field. So you do have to provide that. And the way that the delivery program works, is it just like I said, it returns a true or false the start date. It's kind of determined by what that message had in in the effective date, or you can go around it by doing your own SQL to. If you wanted to try to figure that out there are in the Developer Handbook. @@ -76,15 +78,15 @@ Then you go into a page here now in my notes, I have the navigation and stuff in Once you test the affiliation, you can go validate, obviously, that they, whether or not, they got the affiliation assigned, and in terms of the batch processing. Right? So that's another way that we've talked about. This framework allows you to assign and remove affiliations. And this is where you can see this Pop: Select um query that I created. -I have a section that you know just talks about Hi, what types of things you would need to consider when moving to a higher instance. And then I have a section here regarding the population selection query, because we ran into problems with that as well. So we have way more identities than fifty thousand. But our current uh setup for query is to return a maximum of fifty thousand. That was giving us an error that would have required the DBAs to go in and change a lot of configuration, and and it really goes against even what oracle recommends. Right? So recommended maximum is fifty thousand people books, and they do allow you to change it. But we knew that we would get a little bit of resistance from tba team to do it. So that was another reason kind of a downside of how they how they do this process that they rely on the query tool, which is great for flexibility on the user side not so great when you're thinking through. This could have been written, you know, step based, and and not so intensive. +I have a section that you know just talks about Hi, what types of things you would need to consider when moving to a higher instance. And then I have a section here regarding the population selection query, because we ran into problems with that as well. So we have way more identities than fifty thousand. But our current uh setup for query is to return a maximum of fifty thousand. That was giving us an error that would have required the DBAs to go in and change a lot of configuration, and and it really goes against even what Oracle recommends. Right? So recommended maximum is fifty thousand people books, and they do allow you to change it. But we knew that we would get a little bit of resistance from tba team to do it. So that was another reason kind of a downside of how they how they do this process that they rely on the query tool, which is great for flexibility on the user side not so great when you're thinking through. This could have been written, you know, step based, and and not so intensive. -I provided some links to some of the like the people books on how to set up the affiliations, how to manage them. And then um, just if you're interested in information about. When it was released, the Developer guide, the constituent web services, and then the two presentations that I found on HEUG. So are these available uh to uh people that aren't people to have customers, or are they? What's that? Some of these? So like the people books that you can just access that if you'd like um. Some of the stuff like uh these notes would be only with a login, and to my oracle support, I think the developer guide is also behind that. Um, and the presentations are, If you have access to the HEUG website, I did it, guys? +I provided some links to some of the like the people books on how to set up the affiliations, how to manage them. And then um, just if you're interested in information about. When it was released, the Developer guide, the constituent web services, and then the two presentations that I found on HEUG. So are these available uh to uh people that aren't people to have customers, or are they? What's that? Some of these? So like the people books that you can just access that if you'd like um. Some of the stuff like uh these notes would be only with a login, and to my Oracle support, I think the developer guide is also behind that. Um, and the presentations are, If you have access to the HEUG website, I did it, guys? Laxmi Malladi: So how how long did it take to configure and do the customization stuff? That is a great question. Um, -Pery Doan: tell me to remember +Pery Doan: Help me to remember -Tommy Doan / SMU: when you get started on the project? Well, I know that we engaged a consultant to bootstrap us. That was in the June timeframe, I believe. And then we went live last week. +Tommy Doan / SMU: When did you get started on the project? Well, I know that we engaged a consultant to bootstrap us. That was in the June timeframe, I believe. And then we went live last week. Pery Doan: And the consultant spent a lot of time, you know, looking at the delivered framework and just trying to figure out, Can we leverage it? But I don't remember at what point we made the decision, Tommy, that you know what let's just do this combined approach where we are leveraging the setup. I did not show that. But like we are leveraging the affiliation setup, obviouslyfor for our affiliations, and because we're not using any custom app classes or anything. This is kind of what it looks like. And the trigger. Just this automatically gets saved in here. I didn't do this, but when I put it in, it did it. @@ -114,5 +116,5 @@ khazelton - Internet2: So if we do come back to this in some form uh in a couple Tommy Doan / SMU: That will be a follow up conversation. I just thought it made logical sense to get started with Affiliation Framework Number one, because that's what we just put into production. And uh, it's also sequentially where we're sort of starting uh, and then we'll move forward to productionalize or operationalize COmanage, and then Grouper and then midPoint, so that we plan to, continue giving presentations and status updates as we progress through that. -So yeah, if there are um topiCS that we should continue to explore around Affiliation Framework. I certainly want to make time for that. It may be that there are no other questions, or maybe people just need to digest this or go back and watch the recording. All of that is fine, If you'll please let me know if we should have this as Affiliation Framework as an ongoing agenda. Item, we'll make time for that but if not, we'll move forward to the question that Keith posed about how we leverage the Affiliation Framework data downstream. +So yeah, if there are um topics that we should continue to explore around Affiliation Framework. I certainly want to make time for that. It may be that there are no other questions, or maybe people just need to digest this or go back and watch the recording. All of that is fine, If you'll please let me know if we should have this as Affiliation Framework as an ongoing agenda. Item, we'll make time for that but if not, we'll move forward to the question that Keith posed about how we leverage the Affiliation Framework data downstream.