I started working on the CS / HCM split full time while helping Palomar College with their split project in 2011. They went live in October with little to no disruption. Sierra-Cedar was fortunate to be part of Oracle’s Early Adopter Program, which gave us frequent access to the right individuals in the Oracle Campus Solutions group when we needed help. Since Palomar, I have worked on a large number of split projects with a dedicated group of consultants at Sierra-Cedar. At each split client, regardless of their size, type of institution, or split approach, there are a number of common activities. This blog discusses a few of them.
One of the first steps to any split project is determining the level of impact. Once this is known the remediation may begin. The initial assessment
- Unsynchronized Data Designation & Cleanup – This is both easy and super critical in my experience. We developed and carefully tested a list of tables to be cleaned up in the HR and CS database respectively. We store this data in metadata that is used by a number of our utilities. In general, cleaning up the unsynchronized data is a good idea. What this means is that we delete (technically truncate) the data in tables that should not have data in the post-split database. This is a good thing because you get to save disk space, and you run a lower risk of accidentally using stale data. Sierra-Cedar’s utilities include a web page that will generate truncate scripts, rename scripts, and even alter truncate scripts for db2. Unsynchronized data includes pay checks, student enrollment, etc. This type of data, which is the majority of data in the system, is only maintained in one database or the other going forward. If you have a process, page, query, or whatever that uses data that crosses databases post-split, you have an impact. Every school I have visited has impacts, although there are generally a fairly low number. In my experience, it is during this impact analysis that the post-split metadata provides the greatest value. Sierra-Cedar developed a number of utilities that discover impacts based on this data. These are discussed in the next point.
- Customization Impact Analysis – This is a hill you can die on.J If you have a significant impact from the split, this is where you will find it. I separate the split related impacts into two categories as follow. The first category, “update impacts”, is custom code that creates/updates/deletes synchronized data (e.g. emails address, job data, etc.), for example, a custom routine that adds student emails to the person data. (I see these email processes every week.) The second category, “read impacts”, is custom code that reads data across databases, for example, a Query or SQR that joins enrollment information to pay check information for course costing.. I also see a lot of work study reporting that joins Financial Aid information to pay check data. The trend I have observed is that most institutions have a handful of “update impacts” and a moderate number of “read impacts.” Sierra-Cedar has developed utilities that will find impacts in Queries, SQR’s (and other text based files – Java, SQL, ASP, etc.), and PeopleTools objects (e.g., records, pages, app engines, app packages, etc.). Thanks to our utilities, it generally takes less than a day to find most impacts! This is an area where we have been saving people loads of time.
- Customization Impact Remediation – Once you identify your impacts you must decide what to do. There are a number of patterns in use that are also well-supported by Sierra-Cedar’s utilities. The pattern selected depends on an institution’s budget, architectural approach, and timeline among other factors. Here are the patterns that are most commonly used:“Update Impacts” – If you have a customization that updates person data and does NOT publish the PERSON_BASIC_SYNC and/or the other appropriate messages you need to find a way to keep the data synchronized. For bi-directionally integrated data (person in the subscriber-only model) I generally recommend using the delivered messages. This means your process will need to be message enabled. You can achieve this by converting the modification to use a delivered Component Interface (which will always publish the correct messages). I have clients that are making this investment. I also have clients that choose to leave their customization alone and take a less complex and less costly approach. These clients are making use of the Sierra-Cedar message publishing Application Class library. This library has methods that make publishing the correct messages very easy without changing the existing code structure or behavior. You simply add a few lines of code to invoke the helper methods exposed by the library. While this approach is great for PeopleTools based features, we need to take an extra step with SQR’s and COBOL programs, technologies that are not able to directly publish messages. For SQR and COBOL, we offer Application Engine routines that detect the differences automatically with our Verification Engine or by reading message staging tables populated by the SQR or COBOL. This has proven to be a safe and effective approach. There are others, but these are the most common. You can also make use of the PeopleSoft Enterprise Components Message Publish Utility; however, keep in mind that it is very old, hard to use, and difficult to find documentation for.“Read Impacts” – If you have a query, report, or process that accesses unsynchronized data from both CS and HR you need to make the data available to the process in order to keep using it. Every institution that I have worked with has a number of these. They are usually driven by a handful of tables. Keep in mind that Oracle DOES synchronize basic job data, which in my experience has dramatically reduced the number of “read impacts” for our clients. There are a number of ways to make the data available to the impacted process. I have employed the following with my clients the most often: database links (or equivalent), table replication (everything from Golden Gate to homegrown stuff), and custom messaging. I generally avoid custom messaging unless it makes sense. I tend to recommend what is most appropriate for the given client based on their technology comfort, budget, and timeline. Fancy, complex solutions can end very badly if the institution cannot govern them effectively with their own resources.
I hope this helps and good luck with your split efforts!
Want to learn more?
Myron Wintonyk, PeopleSoft Student Architect at University of Calgary, and I will be co-presenting a Technical session titled Split
Technical Deep Dive of “Subscriber-Only” Split integration Model on March 19, 2012, 12:45 PM – 1:45 pm.