WSDL to Component Interface Faults

本文探讨了使用PeopleSoft组件接口(CI)通过Web服务进行交互时遇到的问题及解决方案,特别是如何有效处理调用CI时出现的错误情况。

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…

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值