Frustrating CI Issue PSBusComp error

I've been having an issue when connecting to a CI (peopleTools 8.49.11) in that as I start working with a component and iterating through data to dump in, there seems to be a point where the OS kills the process that I am using.

Here is what I am doing:

Pulling the rows to insert directly from the DB
Connecting to a CI via JSL to the App server
Start the Loop to pump the data in
The first rows go in well
The the App server kills the run after 1 or two rows
Session is reset

I have interactive mode off, get and edit history are also off.
It seems to be specific to this component, or component type (the size?). Our Admins tell me it is a segmentation falt and the process is killed by the OS. Thanks Mr. OS! :)

There doesn't seem to be any Cobol or really intensive people code. Technically this shouldn't matter as interactive mode is turned off and I don't get to the point of saving, so it should be triggered.

I don't know if it matters, but I am going to check to see if 'Expert Entry' is enabled on the user that is connecting to the app server.

More to come....

Clean Up PeopleSoft Registry entries from CIs

Over the past couple of months I have made _alot_ of changes to my CIs and have had to
re-build then and re-register them etc etc... but the problem is that when I
have to update the client end, and re-register the tlb methods, I don't have a
'Clean-Up Entries' check box.

So.... To clean the registry from the last registered TLB, take the .reg file which starts:

[HKEY_CLASSES_ROOT\TypeLib\{D991A0F6-EFDC-480E-A3B7-DED9BB542536}\PeopleSoftGeneratedKey]
@="Sun Aug 31 23:45:09
2008"[HKEY_CLASSES_ROOT\TypeLib\{D991A0F6-EFDC-480E-A3B7-DED9BB542536}\1.0]
@="PeopleSoft_PeopleSoft"[HKEY_CLASSES_ROOT\TypeLib\{D991A0F6-EFDC-480E-A3B7-DED9BB542536}\1.0\0\win32]
@="c:\\ps\\8.49\\bin\\client\\winx86\\PeopleSoft_PeopleSoft.tlb"

Get your favorite text editor that has Regular expression capabilities (I use Crimson Editor, just casue it is free and does a lot of neat things).

Find: @.*
Replace with nothing

Find: \*\*.*
Replace with nothing

Turn off Regular Expression

Find: [
Replace with: [-

Copy and Paste the whole .Reg file to excel, and sort the column A-Z, to make the longest (deeper branches first) entries go to the top of each group, copy and paste it back to the reg file. Save it to a new name so you have your orignial, and then run it... the [-Branch Name] removes each entry.

CIs: Connecting to PeopleSoft Jolt sever from VB.net. Why & How. Part 4

[If you are looking to Load 100k+ rows into PeopleSoft quickly, this isn't the post for you! This is a multi post piece on Component Interfaces. Hopefully it is informative reading...]

Part 4

A nice thing about interactive mode is that is just that. If you set a field and that updates antoher, you can directly call that other field and the value is there. That is if InteractiveMode is turned on, of course.

Each level and scroll of the component buffer is setup as a collection that can be referenced directly or looped through as in the sample code. For each sub level0 collection there are methods for inserting and deleting items. To use 'Ci_collection.insertitem(x)' x equals Ci_collection.count.

In the sample Code you can see each level is in a For loop. This is good if you are reading out all the rows in the buffer, but for writing you want to jump to either insertingnewitem(collection.count) or oLvlTwo = oLvlTwoCollection.Item(5) unless you do need to cycle through them to find what you want to update etc. You don't need the 'set' statements in .Net. oLvlTwo = oLvlTwoCollection.Item(5) pulls item 5 from the collection and gives it to an object that allow access to that level's fields.

Another Key to CIs, especially in .Net is once you have saved or determined programatically that you don't need the CI anymore, cancel it. Use the .Cancel() function on the CI object. Each time you save, even if you are going to use the as CI again for a new transaction, cancel it and Get/Create it again. You can still read from it or change it in it current state, but once you want to move on to a new rowset etc, Cancel first.

One benifit of using CIs is that the user has to provide credentials, and have access in order to be able to use the CI. This means you are relying on out of the box functionality, which is always nice.

To bring this to a close, there is obviously a lot missing from these short posts, but the point was to point out that although Component Interfaces seem old technology and come with a bunch of over head, they can still be VERY useful when you need a custom solution to a problem and want to leverage the application tier.

CIs: Connecting to PeopleSoft Jolt sever from VB.net. Why & How. Part 3

[If you are looking to Load 100k+ rows into PeopleSoft quickly, this isn't the post for you! This is a multi post piece on Component Interfaces. Hopefully it is informative reading...]
Part 3

The file is laid out in two Subs. ErrorHandler and main.

ErrorHandler is generic for all CIs. Call it often! One of the major issues I had to deal with was error handling. Wether you use PeopleCode or VB or Java, you must handle errors well. If a CI hits an error it freezes; just like in the web front end. Until you clear the messeges, the CI is unusable.

In using .Net, in the ErrorHandler sub there is a problem. The line:

oPSMessageCollection.DeleteAll

This clears all the messeges and thus allows the CI to continue. It returns a var bool type (Boolean) but the problem is that is in type format that .Net doesn't like. I have tried marshaling it Ctyping it  etc... to no avail. The only way I could maked it work as to late bind as an object and set the property.

 

Dim o As Object = oPSMessageCollection

      Try

        o.DeleteAll()

      Catch ex As Exception

msgbox("Problems clearing Msgs.")

       End Try

That was the source of a lot of greif in the begining... After I got that issue sorted out, CIs became an option.

The sample code is well documented and allows you to copy and paste a lot of stuff. 'Try' statements are handy for the major parts of Get / Find / Create, allowing you to retry and handle errors nicely. Notice the statements for writing data are commented out, and read only properties aren't available to be set.

The sample code also showing good practice in setting up the CI by setting the three modes for a component. InteractiveMode, GetHistoryItems and EditHistoryItems. If users don't need instant feed back for each item entered, you can increase performance by setting InteractiveMode = Flase as the app server will only process all the data items at Save time, therefore eliminating a lot of overhead.

CIs: Connecting to PeopleSoft Jolt sever from VB.net. Why & How. Part 2

[If you are looking to Load 100k+ rows into PeopleSoft quickly, this isn't the post for you! This is a multi post piece on Component Interfaces. Hopefully it is informative reading...]

Part 2

Since to Topic of this post is CIs lets get started... (finally :)

To start using CIs we have to have our environment set up to handle using the COM object front end of the java classes that actually do the work. We have to have enviromental variables set:
If these already exist, obviously just add missing parts...

CLASSPATH=C:\PS\8.49\web\psjoa\psjoa.jar

PATH=C:\PS\8.49;C:\PS\8.49\jre\bin\client

C:\PS\8.49 is where my PeopleTools is located.

As for what is needed for a peopleTools CI only environmnet, you don't need to whole thing. Here are the files that are needed:Everything under .\jre and \webIn .\bin\client\winx86:

dbghelp.dll

msvcp71.dll

msvcr71.dll

psapiadapter.dll

psbtunicode.dll

pscmnutils.dll

pscompat.dll

pslibeay32.dll

pspetssl.dll

trio.dll

zlib1.dll

PeopleSoft_PeopleSoft.reg & PeopleSoft_PeopleSoft.tlb are what you get when you build the PeopleSoft APIs from appdesigner.

Once the PeopleSoft_PeopleSoft.reg file is registered (More about cleaning up CI registry entries in a bit) you may need to restart to have the environmental variable available etc. (I've found that it does wonders, thanks M$). Add a reference to the Peoplesoft_peoplesoft.tlb to a .Net project. You can import the reference as to not have to type peoplesoft_peoplesoft all the time.
In order to get familiar with the code, I'd like to suggest that you take a look at the demo code that you can generate by right clicking on your CI from app designer and selecting the generate visual basic template. This is in VB6-or-less layout in a .bas file.

Stay tuned for part 3.

CIs: Connecting to PeopleSoft Jolt sever from VB.net. Why & How. Part 1

[If you are looking to Load 100k+ rows into PeopleSoft quickly, this isn't the post for you! This is a multi post piece on Component Interfaces. Hopefully it is informative reading...]

Part 1:

There have been a lot of times when we have needed to mass load some sort of data. One of the main issues as always been load directly into PeopleSoft DB tables is just yucky... :) Some times unavoidable, but almost always yucky... I guess i should explain what i mean by yucky... The clearest example is person bio demo data. When you use 'add/update a person' to add a new person the emplid is give to you, the person's data is strewn over a plethora of tables and all the effective dating stuff is taken care of for you. Not to even touch on search match possibilities; cause we all love dupes so much...

Moving data around between platforms is always a headache. Then there is the migraine called synchronizing data... anyway, say you have an application that really needs data moved from it to Oracle's PeopleSoft. You could write something to connect to both DB and just pass data back and forth, but you want a solution that is more flexible, able to be used by an end user (securing DB level access for end users, do i need to say more...) and you want to be able to leverage data validation from the application tier. Sounds great. You have two options: CI or Web service.

As of 8.48, web services are a good option, but they are still lacking some (this could totally be from a lack of understanding from my part) and are a little ... um.. clunky?... when it comes to dealing with re-posts and data validation. They are great for posting small data objects from remote systems that you can almost be curtain the data is always good.

I have come to really have an appreciation for CIs. At first I really didn't like them because of the fact that they are based on old COM objects, don't work too nicely with .Net (I now have some tricks... :), setting up the environment was a pain, maintaining distributions was painful too and they are inherently SLOW (slow-as-a-wet-week). After I overcame these little hurdles, or learnt to live with them, the results are quite workable.