List of Design Patterns

AE Row By Row Publish (application engine row by row publish)

In this design pattern, the transaction or setup data that you want to send out of the PeopleSoft system is updated by use of an Application Engine program that performs procedural (row-by-row) processing; you want to publish these changes. Generally, messages are used with this design pattern.

Batch Publish

Use this design pattern to publish messages from a batch application. The batch application can be a COBOL or Structured Query Report program that takes either a procedural or set-based approach, or it can be an Application Engine set-based program.

Batch Subscribe

This design pattern enables you to perform edits against messages in sets. This can be a useful technique for high volume data, including millions of inbound rows. This design pattern is useful when you know that a single message definition may contain multiple instances of a transaction, or when you must reuse an existing batch program.

CI Subscribe (component interface subscribe)

This design pattern uses a component interface to edit incoming message data. This enables you to reuse existing business rules when processing data.

Component Publish

In this design pattern, the transaction or setup data that you want to send out of PeopleSoft is being updated by using a PeopleSoft component. In this case, the data is already in the component buffer, and the Publish PeopleCode function is used to publish a message.

EDI In

This design pattern is for inbound EDI documents.

You should use EDI only for existing EDI manager inbound transactions that must be supplied to an EDI partner, and you want to allow subscription to an XML message, or when you need to comply with other industry standards, such as SWIFT, BAI, or HL7, that have an existing EDI manager inbound map, and you want to convert to subscribing to an XML message.

EDI Out

This design pattern is for outbound EDI documents.

You should use EDI only for existing EDI manager inbound transactions that must be supplied to an EDI partner and you want to allow subscription to an XML message, or you need to comply with other industry standards, such as SWIFT, BAI, or HL7, that have an existing EDI manager inbound map, and you want to convert to publishing to an XML message.

Full Table Publish

Use this design pattern to populate an entire copy of a table onto a remote database or legacy system. Generally, full data replication occurs with setup tables, or relatively static, low-volume tables that are keyed by setID. When a copy of a table exists on the remote system, incremental updates can be used.

Full Table Subscribe

Use this design pattern to subscribe to messages that contain an entire copy of a table that is published from a remote database or legacy system. Generally, full data replication occurs with setup tables, or relatively static, low-volume tables that are keyed by setID. When a copy of a table exists on the remote system, incremental updates can be used.

No Pattern

No design pattern is specified.

PeopleCode Subscribe

Use this design pattern to subscribe to messages by using a PeopleCode program when additional processing is required. Use PeopleCode subscription when simple edits or no edits against the inbound data are needed before you insert the data into the application tables or staging tables.

Sync Reply

In this design pattern, another system initiates a request for information from the PeopleSoft system and waits for information to be returned. This information must be provided by the PeopleSoft system in a real-time synchronous mode and in a conversational style of interface before the other system can continue processing. Generally, business interlinks are used to satisfy this type of request.

Sync Request

Use this design pattern when a PeopleSoft application must call a third-party vendor’s application to request information. This information must be provided in a real-time, synchronous mode. Generally, business interlinks are used to satisfy this type of request.

XML Reply

In this design pattern, another system initiates a request for information from the PeopleSoft system. This information must be provided by the PeopleSoft system in a real-time synchronous mode and in a conversational style of interface before the other system can continue processing. Generally, XMLDocs are used to satisfy this type of request.

XML Request

Use this design pattern when a PeopleSoft application must call a third party vendor’s application to request information. This information must be provided in a real-time, synchronous mode. Generally, XMLDocs are used to satisfy this type of request.