Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. | ||
| --Rich Cook | ||
Of all the popular ERP packages, PeopleSoft is the most open. Which is not to suggest that it is simple or easy to use. This beast is actually very difficult. It provides the least amount of information on how it can be integrated with the rest of the enterprise. In fact, obtaining information for this chapter was a bit of a challenge. Fortunately, there are enough projects, and vendors muddling through with them, to allow us to elucidate some basic approaches.
PeopleSoft is significantly less proprietary than SAP. As such, it provides greater opportunity for integration without forcing the EAI architect and developer to rely on the vendor interface. These interfaces are, however, hardly cut and dry. In order to create an optimal EAI solution, it is necessary to understand the native and enabling technologies of PeopleSoft.
This world, however, could be changing for PeopleSoft. PeopleSoft has already announced and loosely defined their Open Integration Framework (OIF). While OIF does not define their EAI technology in detail, it does more clearly outline the options that are available to those looking to integrate with PeopleSoft, including up-to-date mechanisms such as XML and their latest Business Component API appearing with PeopleTools 8 (discussed later in this chapter).
Like SAP, PeopleSoft uses standard relational databases for information storage, allowing for the possibility of mixing and matching databases between modules (see Figure 15.1). The databases provide the best point of integration—as long as there is no need to access the business processes that are encapsulated within the application itself. There are ways to accomplish this as well but not as readily.
Unlike SAP, the PeopleSoft application server is based on open technology—BEA's Tuxedo. Because there are tools and techniques to access transactions on the Tuxedo platform, there is another point of integration. In spite of this additional benefit, PeopleSoft does not promote going directly to the application server (TP monitor).
PeopleSoft relies on a three-tier client/server architecture, with a client, an application server, and a database (see Figure 15.2). The client communicates with the application server, which in turn communicates with the database. This architecture provides PeopleSoft with good scaling capabilities as well as an extensible architecture.
The supplemental products offered with the PeopleSoft application solution include:
PeopleSoft Financials
PeopleSoft Distribution
PeopleSoft Manufacturing
PeopleSoft HRMS
PeopleTools
PeopleSoft Financials provides a general ledger system, payables, receivables, asset management, projects, budgets, treasury, and expenses. PeopleSoft Distribution provides purchasing, inventory, order management, billing, enterprise planning, demand planning, and product configuration. PeopleSoft Manufacturing provides bills and routings, production management, production planning, cost management, engineering, and quality management. PeopleSoft HRMS (Human Resources Management System) provides payroll, time and labor, pension administration, FSA administration, benefits administration, and stock administration. PeopleTools is an application development environment that enables the PeopleSoft developer to customize, maintain, and implement PeopleSoft applications without changing the PeopleSoft source code. PeopleTools provides facilities for modifying panels, records, and menus, as well as importing information from other systems. PeopleTools also provides a facility for reporting.
Although the methods for moving information in and out of PeopleSoft are not well defined, it is possible to define several approaches to PeopleSoft integration at the data and interface levels.
Fundamentally, data-level PeopleSoft application integration is data-level EAI as described in Chapter 2. This means that information can be moved in and out of PeopleSoft-supported relational databases (including Oracle, Informix, and SQL Server) in order to integrate PeopleSoft with other external applications at the data level. This is accomplished with any number of database-oriented middleware products, message brokers, data migration software packages, or even with the replication and data link features contained in most popular relational databases.
In this, as in any other data-to-data integration effort, it is necessary to first understand the structure of the database or databases from which information is being extracted, as well as the structure and integrity features of the database that is receiving the data. PeopleSoft provides EAI architects and developers well-defined database schema information and a built-in database movement facility (although not real time). This includes the Data Mover and SQRs and leveraging the PeopleSoft Workflow interfaces.
The PeopleSoft Data Mover is a platform-independent PeopleTool that provides the user with the ability to transfer data between PeopleSoft databases. Data Mover also provides the user with the ability to unload and reload data from other external, non-PeopleSoft databases. Data Mover may also be used for archiving data. Although this is a useful tool, more traditional database-to-database integration solutions may be the better choice.
PeopleSoft provides a tool known as SQR, a reporting tool that's a part of all PeopleSoft applications. This tool allows for the exchange of data between two databases with different data structures. In order to use this tool for data movement, two SQR procedures must be written first. The first procedure runs against the source database, selecting the appropriate data. This information is then placed into a sequential file. A second SQR procedure is then created to read the sequential file and update the target databases (see Figure 15.3). PeopleSoft Process Scheduler allows the user to schedule regular transfers of this information. (This is not a real-time solution but more of a batch-oriented one.)
Within the PeopleSoft environment, workflow activities and worklists can be triggered to established database agents. These database agents are able to monitor one or more tables in the databases, searching for conditions that should trigger an event. Using features found in most relational databases, such as database links, workflow activities can also be triggered by events occurring within remote databases.
Workflow activities for multiple databases are set up by first creating the appropriate external tables as database links from the source database (if supported), then creating an agent to monitor the tables awaiting an event (such as a change in state, deletion of a row, or insertion of a row). This mechanism may be leveraged for EAI by using the agent to watch for changes in the source database, such as a table update. When such an event occurs, a stored procedure or replication process could be fired off to move the appropriate data from a source database to a target (see Figure 15.4). In this way, a "mini message broker using intelligent agent technology" is being created. It should, however, be noted that this PeopleSoft mechanism was not designed for database movement exclusively.
There is nothing remarkable about PeopleSoft's database-level integration approach. It is independent of the application, leaving the user to deal with the package at the database and database middleware level. Leveraging some of the other interfaces that PeopleSoft provides for accessing not only the data stored in the application, but the business information as well (e.g., invoices, work orders, accounts receivable reports, and so on) requires a bit more sophistication. Grading this aspect of PeopleSoft earns it a C– (SAP isn't much better, earning only a C) for the quality of interfaces that it provides for this purpose. Fortunately, most EAI middleware vendors (e.g., message broker vendors) provide interfaces to PeopleSoft. As a result, it may be possible to obtain appropriate technology and avoid having to understand the details of the interface.
Proper integration of PeopleSoft with the rest of the enterprise requires an understanding of other existing interfaces. As the PeopleSoft product matures, it's a good bet that PeopleSoft will enhance its business-oriented interfaces, opening up the PeopleSoft processes for other systems both inside and outside the enterprise.
Scraping screens to access application information has always been a viable option. In this regard, PeopleSoft is consistent with existing products. Using 3270, ASCII terminals, or even Windows user interface access mechanisms (e.g., COM automation), it is possible to extract information from PeopleSoft. In fact, most of the interfaces that PeopleSoft provides at the application level already scrape screens.
While there are many ways to move information in and out of PeopleSoft, most consider the Electronic Data Interchange (EDI), which exists to exchange business information with systems existing outside the enterprise, to be the best overall solution. Although the PeopleSoft EDI interface was not created for EAI, it certainly works effectively in the EAI domain.
The PeopleSoft EDI is like any other EDI interface in that it is necessary to map the information contained within it in order to transmit it outside PeopleSoft. Once outside the PeopleSoft environment, the information may move to any system that understands EDI or be reformatted by a middle-tier middleware layer, such as a message broker or an application server (see Figure 15.5). Such reformatting assures that the target system will understand the message.
In the context of EAI, EDI is a simple method to get at relevant business data. It represents a method of "tricking" the PeopleSoft system into believing that information is being moved to and from a system existing at a trading partner. In actuality the interface is being used to exchange information between systems within the company. The enabling technologies that will make short work of this include: EDI-mapping software, message brokers that can read and write EDI (EDI adapters), application servers with EDI connectors, and traditional queuing middleware such as MQSeries.
If this technology is not beyond the budget of the corporation, it could very well be the best bet for situations requiring the exchange of application information and not just simple data.
The PeopleSoft Workflow subsystem enables the user to integrate rules, roles, and routing associated with the localized processing of the enterprise (workflow will be discussed in more detail in Chapter 19). Clever EAI architects and developers may incorporate this workflow mechanism as a method to integrate PeopleSoft with other applications. While the database agent has been discussed previously, it is possible to use similar techniques to send and receive electronic forms and messages.
The PeopleSoft Application Designer can be used as the graphical tool for creating visual business process maps to define workflow scenarios. Once again, while this feature was not created for EAI, moving information between PeopleSoft modules is particularly suited to the needs of EAI in that it creates the opportunity to move information out of PeopleSoft.
The PeopleSoft Workflow subsystem provides a Message Agent API that allows third-party applications to integrate with PeopleSoft Workflow. This interface processes electronic messages sent to and from PeopleSoft. These messages may be sent through COM automation, a C program, or Windows DDE (Dynamic Data Exchange) as well.
PeopleSoft's Business Component API, new with PeopleTools 8, allows internal and external applications to invoke business rules encapsulated within PeopleSoft. The Business Component API is also able to perform simple data access operations. This interface provides a high-level abstraction layer hiding the complexities of the PeopleSoft system from developers that invoke the Business Component API.
The Business Component API employs online business component logic running through a set of processing events. When creating the logic, business component-specific events provide the infrastructure for sharing components between external applications and transition logic. This API is accessible through C++ or COM and is analogous to SAP's BAPI.
In addition to moving information between databases, or using the workflow or EDI interfaces, it is possible to integrate PeopleSoft with other applications that traditionally exist on the desktop. By using utilities that are provided within PeopleTools, it is possible to invoke another workstation application. For example, the WinExec function can be run synchronously or asynchronously. This mechanism is used to launch such Windows applications as Microsoft Excel.
PeopleSoft also supports COM automation, allowing PeopleSoft to control a Windows application through this standard interface. PeopleTools includes a set of COM functions that allow PeopleSoft applications to appear as a COM automation client on a COM automation server existing on a Windows-based PC (see Figure 15.6). These functions include creating an instance of a COM automation object, obtaining COM properties, setting properties, and invoking methods existing on the automation server. DCOM may also be used to extend COM automation over a network as a true distributed object.
Figure 15.6. PeopleSoft is able to be a COM automation client to another application existing on a PC.
In addition to supporting COM automation, PeopleSoft also supports external DLL using the PeopleCode scripting language. This feature allows PeopleSoft applications to call an external C function defined in a Windows DLL library, giving the developer a low-level interface to hook PeopleSoft into desktop tools and applications.
Of course, it is also possible to access PeopleSoft data by using ODBC and going directly to the databases. This method allows you to view PeopleSoft data within any Windows application that supports ODBC, such as Visual Basic and Excel (see Figure 15.7).
Before integrating PeopleSoft with other enterprise applications, it is necessary to understand the architecture, the modules, and the various interfaces available. In addition, it is advisable to be familiar with the details of the database schema along with the best mechanisms to get at the data. For most EAI projects, the best method to access PeopleSoft information is through the standard database interfaces. Standard technology—including database middleware, data replication and translation software, and message brokers—allows for access and movement of data, as well as the translation of the schema and content.
As with every other data-level approach, it is important to consider both data integrity issues and how the data is bound to the application logic. PeopleSoft provides most of the necessary information, but testing and then retesting is still a smart move to ensure that a particular EAI solution is the correct one.
The PeopleSoft application interfaces are adequate. The EDI interface is the best choice for moving business information in and out of PeopleSoft. It's designed to share information with external systems, making it a good mechanism to exchange business data with other applications both inside and outside the enterprise. Unfortunately, like most EDI-based EAI solutions, the enabling technology is expensive. What's more, it is difficult to move information out of PeopleSoft on a real-time basis, near time being the best to be hoped for.
While the workflow interface shows real promise, it's still not much more than a mechanism that uses agents to monitor and react to events as it moves data between databases. If PeopleSoft could build on this interface, and provide true message brokering features, it may be better able to open its business information to the outside world.
The workstation integration tools are little more than methods to integrate PeopleSoft with a Windows-based PC, providing only rudimentary mechanisms to share information and methods. Not only is this handy for client-to-PeopleSoft integration, it may also prove useful to EAI architects and developers looking to integrate PeopleSoft as a set of COM objects. PeopleSoft, however, needs to do some more work here to make complete integration through COM a reality.
PeopleSoft will continue to be a leading ERP in the packaged application marketplace, second only to SAP in the number of installations. As the PeopleSoft installations settle in for the long haul, integration will become the next big problem to solve. In an effort to solve this problem, look to PeopleSoft to shore up the interfaces into their software.