Author Info
Chris Malek

Chris Malek is a PeopleTools® Technical Consultant with two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

About Chris Work with Chris
Looking for pain-free PeopleSoft web services? 😀
PeopleSoft Simple Web Services (SWS)

Introducing a small but powerful PeopleSoft bolt-on that makes web services very easy. If you have a SQL statement, you can turn that into a web service in PeopleSoft in a few minutes.

Read More & Purchase
Contents
0. About Book
1. Getting Started
2. Service Operations
3. REST Services
4. Security
5. Monitoring & Administration
6. Example Service Operations
7. Data Encoding/Decoding
8. Nodes
9. Services Delivered by Oracle
10. Listening Connectors - PeopleSoft as a Server
11. Handlers
12. Target Connectors - PeopleSoft as a Client
13. Syncing Data Between PeopleSoft Systems
14. API Gateways
15. Best Practices
Search

Integration Broker Technologies to Avoid

Best practices are often a list of things you “should do”. Those are great. There are often NOT lists of things you should NOT do. Here are a few that come to mind.

  • Do NOT use SOAP
  • Do NOT expose Component Interfaces directly as web services. Please read Should You Expose a Component Interface as a Web Service for more detail
  • Do NOT use Documents for JSON Parsing. See Document Messages for detail
  • Do NOT use XML Schema Validation
    • I personally never turn on “Schema Validation” or use XML Schemas. The reason for this really comes down to flexibility in a production environment.
    • If you use Schema validation the integration broker will reject any messages which do not conform to the rules at the “front door”. This does not allow your custom handlers to even see the message. While this sounds good at first, the problems arise when you get into production and things start to change. For most web services, you often have many applications written in different technologies and different vendors. Your code and requirements will change over time. The clients and servers are often rarely in sync and releases are not coordinated. So what ends up happening is that you need to change the web service over time to add new required fields or change the structure in subtle ways. The clients often take time to “catch up” to the functionality if they ever do. If you ask the IB system to perform schema validation, this can get in the way.
    • Let’s say you have a required field that was introduced. However, one client cannot send that field due to the vendor frozen code. If you ignore schema validation, your handler code can detect that the client is not sending the new required field and potentially default that for them at run time. Or let’s say one vendor cannot produce the exact schema string due to some bug. That is fine, if you are NOT using schema validation, and you let your handler code account for this at run-time.
  • Do NOT use Excel to CI - Excel to CI is a powerful tool for one time conversion or quick updates. However, I one simple incorrect copy and paste error can wreak havoc on your system. I have seen this happen in many cases. A person thought they were updating test, and they were updating DEV, all because of a simple typo.
  • Avoid WSDL, it almost provides no value in my experience. The dream of WSDL is that you could import some WSDL and some API client would magically generate code to interact with the API. This is science fiction. I have never used WSDL for anything. Don’t waste your time.
  • XML Namespaces - I have never seen them used in practice. Systems may send you XML with name spaces that you cannot avoid. However, don’t worry about creating name spaces in new web services.
Copyright 2018-2024 Cedar Hills Group, Inc. All rights reserved.