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
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
I have been working with PeopleSoft since 2000 AD 👴. I work with varying levels of technical and functional staff. I often see teams reach for “flat file” integrations and SFTP servers to transmit data. I don’t think flat-file integrations will ever go away. However, I always try to avoid that approach if both sides of the integration can handle it. I often have clients fight me on using integration broker and web services. The reason is that their staff may not know what web services are or the advantages of using them. Or they tried to use PeopleSoft web services and ran into one of the many rough edges and gave up because the documentation is so horrible. Hopefully, this book will help with this last road block. 😀
Let’s discuss some reasons why web services are better than flat files and FTP servers. Let’s look at an example where a file is being sent into PeopleSoft for processing. Here is a rough overview of the FTP flat-file components.
What could go wrong and what pieces are there to maintain?
Let’s look at the components when a web service is used.
With Flat File integrations, you often see one file with many transactions that are processed. You could have a “clean” file and all the transactions are processed correctly. However, you often run into situations where a few rows in a file cannot be processed correctly. As mentioned above, this requires some design and a contract between the client and server on how those issues are communicated back.
When you migrate to a web services approach, it is often beneficial to design the web services around a single transaction. This is not a requirement, but you will find it beneficial in the design. It often simplifies the “contract” between the client and the server.
For example, Let’s say that you have an inbound file that that triggers the creation of user accounts in your PeopleSoft system. If we imagine that you have a PeopleSoft Finance system and some other HR system. The HR system tells the Finance system that new accounts need to be created when someone is hired.
The web service could easily be designed to handle multiple transactions. The issues arise around partial failures. If you design a good message structure where you can signal back partial failures it will work just fine. However, I have found it is often the most simple approach to gear your services around one transaction. So if this is a web service that is geared around a person like updating an address or adding some data the service would take one EMPLID at a time.