WSDL to Component Interface Faults

来源:互联网 发布:公司 数据分析 编辑:程序博客网 时间:2024/04/28 03:06

Component Interfaces is one of the coolest features in PeopleSoft from a technology point of view. The folks in Pleasanton either had great deal of prescience (or were extremely lucky) when they designed the Component framework to so easily be encapsulated and accessible using a variety of interfaces. By its very nature MVC implies this kind of design property but so far I have yet to see something similar in any of the other software packages I have dealt with. Perhaps the fact that the metadata is wholly stored in the database and that view components cannot have any logic outside of PeopleCode enforces a clean break between the view and the controller. This compared to other technologies where the view is too tightly bound to the model and/or logic to make such a partition costly and – in some instances – impossible.

Anyways, boring stuff to anyone but myself.

Given how much CI is touted in the marketing materials, you’d be surprised at the dearth of information available. PeopleSoft provides a rather poorly documented SDK_BUS_EXP (oh geez, thanks) and there are a few How-Tos in the Oracle Support Knowledge Base. Documentation for implementing CI over Web Services is especially impoverished considering that most of the Oracle (nee PeopleSoft) documentation stops after creating the the web service itself, failing to show any examples of how to actually implement the service consumption side.

Currently I have been using C# .NET 3.5 / Visual Studio 2008 to consume a PeopleSoft CI-based web service. After having created a Service Reference I was greeted with a bizarre assortment of “types” and absolutely no documentation for what to do next. After much toil I was able to throw together a small console application that allowed me to perform all of the operations exposed by the CI including Create, Find, Get and Update. However, to my dismay I was unable to get any meaningful error conditions back from my calls to the CI.

Specifically, any errors would throw and exception with a simple message: “Component Interface API”. Debugging seemed fruitless as none of the variables contained any error messages or indication of what actually went wrong.

The point of this entry is to say simply that the following code will show you the error messages (specifically the SOAPException) from a failed CI call (excuse the lack of indenting):

catch (System.ServiceModel.FaultException e)
{
System.ServiceModel.Channels.MessageFault messageFault = e.CreateMessageFault();

if (messageFault.HasDetail)
{
XmlElement faultDetails = messageFault.GetDetail<XmlElement>();
foreach (XmlNode node in faultDetails.ChildNodes)
{
Console.WriteLine(node.Name + “: ” + node.InnerXml);
}
}
Console.WriteLine(“Exception: ” + e.Message);
}

Hope this helps someone. The tip jar is looking awfully broke these days…