'I am using a component interface for inserting a row into a certain component through standard machine-generated peoplecode. Although I made sure through 'Test component interface' that the names of the fields of one table into which I am inserting are correct, the insertion fails to happen. The table into which I am inserting has five fields out of which the first four are key fields. The names of three of these four fields are suffixed with '1' in the component interface machine-generated template (probably to indicate level 1) but the name of the fourth key field is not suffixed. When I assign values to these fields the insertion does not take place. When I put '1' after the names of the remaining key field and the remaining non-key field, the code goes through but nothing appears in the table. What could be wrong?'
A few thoughts If the purpose is to insert rows into a single record then could the Record class API be better suited? I have just replaced two component interfaces (previously written by someone else) with this technique. The Record Class API also allows for updating an existing row if one exists.
The Class also has methods for setting defaults, edit checking, etc. As for the CI, what I suspect you are seeing are the properties which map to the record-fields so when working with the CI you need to be aware of this distinction and yes that means that to prevent a duplicate name the system automatically appends a underscore and a sequential number to the property to help uniquely identify each occurrence. Donkey kong jungle beat iso ntsc. As for the issue of no data appearing, I would check when the Save and Cancel (to close out the CI object) are done. This assumes that a Get, New, etc. Was done initially when the CI was created. There were some of the reasons why I was able to eliminate the CIs by eliminating the objects and reduced the code significantly using the Record class API -Richard. The details may be found in the PeopleBooks: PeopleTools Development Tools PeopleCode API Reference Record Class The example given to insert one row into an existing record: Local record &REC; &REC = CreateRecord(RECORD.MYRECORD); &REC.KEYF1.Value = 'A'; &REC.KEYF2.Value = 'B'; &REC.MYRF3.Value = 'X'; &REC.MYRF4.Value = 'Y'; &REC.Insert; I find the delivered Method 'SetDefaults' very useful so I only need to change what needs changing.
So, to expand the above example and assume that field MYRF3 has a default but that MYRF4 does not: Local record &REC; &REC = CreateRecord(RECORD.MYRECORD); &REC.SetDefaults; &REC.KEYF1.Value = 'A'; &REC.KEYF2.Value = 'B'; &REC.MYRF4.Value = 'Y'; &REC.Insert; -Richard. Depends on what the component does and the business needs. Yes, a CI will trigger any existing PeopleCode but if there is no PeopleCode in the component then why bother with a CI?
Component In Peoplesoft
If a single row is to be inserted then this works just as well with fewer objects and their security to deal with. Multiple rows obviously require a loop of some sort or use a RowSet class There is a lot more to the Record and RowSet Classes. SQLExec has its own host of issues. Yes, it could work but for an INSERT/UPDATE/DELETE the event location can cause much 'mischief' due to side effects. A SQLExec has to explicitly reference the entire structure (or use a SQL object to do it) which is inherent in the Record class. All of this assumes that this is NOT being done via a page so that there is no concern that the records in question are not currently in the buffer.
Still possible but need to see what is going on. Defiance patch error xbox 360. In short, use and manipulate the buffer as needed. As often the case, there may be more than one right answer as to the approach you use, and it may come down to a coin-toss. However consider these: I like SQLExec, however the maintenance is high. Go with the record object if possible.
Peoplesoft Interfaces
It's usually much easier to work with - certainly easier to look at on the compare reports. From a pure academic point of view the component interface is the way to go.until you realize that sometimes they don't do what you thought they would/should do, and that it is doing what an end-user would be doing, including all of the PeopleCode/workflow/messaging, etc. Not good if you are doing a a mass import that is time sensitive. Sometimes you actuallly need to create a custom component and then a custom component interface to do much of what the delivered one does but leaves out some stuff you don't want or need to happen. If the component is complex, and you need all of the business logic to run, then you may have to use the delivered component, but you can also run multiple instances of an application engine that calls a component interface to split up the import.
The code may also trigger Application Package code meaning that the FieldEdit/FieldChange events simply setup some of what is needed by the App Package methods. I found that little gem when I created a CI for expense reports and had to deal with the 'Submit' button. I found that a PeopleCode trace of just the event names AND a full PeopleCode trace helped narrow down what and where I needed to add code to recognize that the CI was running.
Using both made it easier to follow what events were being triggered under various conditions and combinations with the details knowing the exact code run. The component I was working on has 42 pages and lots of app package peoplecode.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |