| To begin with, here is a look at the store files. When a user creates a message, one or more GroupWise information store files are written to. The particulars depend on the type of message. This section explores message flow using a few scenarios. Each of the scenarios in this chapter follows the actions of UserA. UserA's GroupWise file ID (FID) is 123. Based on this FID, USERA is assigned to place all sent items in MSG17.DB. GroupWise Information Store Concepts Before proceeding, let's review some of the information store concepts. Most of this information is explained in Chapter 4, "Understanding the GroupWise Information Store," but for clarity's sake, this chapter reviews it. GroupWise information (messages, address book info, rules, folders, and so on) is contained in the information store, which is composed of individual databases (also called store files). GroupWise information store databases are contained in each post office's OFUSER and OFMSG directories. Databases are composed of records. Every record has a particular set of fields based on the record type. Some GroupWise fields can exceed 2KB. Fields that do exceed 2KB are called external BLOB (binary large object) files. BLOB files are contained in the post office\OFFILES\x directories. Every item in GroupWisewhether it is a mail message, a task, a document, or anything else that can be displayed in a user's mailboxis just a record in a GroupWise information store database. Whenever a field within a record exceeds 2KB, that field is spun off to its own BLOB file outside of the database. The User Database: USERxxx.DB You might recall from Chapter 4 that every user has a user database. This file is named USERxxx.DB, where the xxx is replaced with the user's three-character file ID. The easiest way to explain the user database file is that it is largely a pointer database. When USERA gets a message from USERB, the message isn't actually contained in USER123.DB. The message is contained in one of the message databases. A pointer to that message is created in the USER123.DB file. The user database does contain records that represent complete items, however. For example, a user's folders and a user's personal calendar items are wholly contained in the USERxxx.DB file. Everything you see from the GroupWise client is coming from the user database. You will never look at anything that is exclusively stored in the message database from the GroupWise client. Most of the items you see from the client are simply pointers to the full message in the message databases. The Message Database: MSGnnn.DB Every GroupWise 7 post office can contain up to 255 message databases. Before GroupWise 7 there were only 25 message databases. All messages sent between users in a GroupWise post office are contained in one of the MSGnnn.DB files. Group Items Versus Personal Items When a user receives an email message or an appointment, a task, or a note, that item is considered to be a group item. Group Items are stored in the message database and linked to the user database, with possible overflow to the OFFILES. When a user creates an item in the calendar without sending it (that is, the item has no TO line), this is a personal item, also known as a posted item. Posted items are (only) stored in the user database, with possible overflow to the OFFILES. Message "Body" Parts A GroupWise item is not just one record in a database. There are distinct body parts on a GroupWise message, and every body part has its own record. Every GroupWise mail message has a handful of body parts and records. The master record and the message properties record are always present on group items (items that one user sends to another user). The following explains the different types of body parts in a typical GroupWise message: Master record: The master record contains fields such as TO, CC, BC, and Subject. The master record also keeps track of all the other records associated with the original message. If the TO, CC, and BC lines contain more than 2,048 bytes of data, the master record relies on the message properties record to hold the entire contents of the TO, CC, BC, and Subject lines. Message properties record: The message properties record shows the properties page of a message. If the contents of this record exceed 2KB (this happens often when sending to distribution lists), only the header of this record is kept in the MSGn.DB file. The remainder is spun off into a BLOB file in the OFFILES directory. Because the message properties record must contain the recipient list of the TO, CC, and BC lines, it becomes the master list for the TO, CC, and BC lines. Message body record: This record contains the text and attributes of the GroupWise message's message area. If the message text is more than 2,048 bytes in length, this record will be spun off into a BLOB file in the OFFILES directory. Attachment record: Each attachment has its own record. The attachment file is a field in the attachment record. If the attachment exceeds the 2,048-byte limit of the attachment field, it is spun off into the OFFILES directory.
Scenario #1: USERA Creates a Personal (Posted) Calendar Item In this scenario, USERA creates a posted calendar appointment. The subject of the appointment is simply "Test". There is not a message body, or any attachments. Here are some observations: GroupWise puts the master record for the appointment in the USER123.DB file. GroupWise creates a message body record for the body of the appointment. This also goes in USER123.DB. A separate alarm record is written to the USER123.DB file. GroupWise Notify reads this alarm record.
Note If an attachment had been made to the appointment, an attachment record will be created.
Scenario #2: USERA Sends a Message to USERB on the Same PO as USERA In this scenario, USERA creates a short message with no attachments and sends the message to USERB: USERA's FID is USER123.DB. USERA's message database for outgoing messages is MSG17.DB. GroupWise creates three records in MSG17.DB. In this example, the master record is record #12 in MSG17.DB, the message properties record is record #11 in MSG17.DB, and the message body record is record #13. GroupWise creates a pointer in USER123.DB with a pointer to record #12 in MSG17.DB. GroupWise further indicates that this is a message sent by USERA. GroupWise creates a pointer in USERB's database. USERB's FID is 789, so USERB's user database is USER789.DB. The pointer indicates that this is an inbox item. The pointer also indicates that the record is record #12 in MSG17.DB. GroupWise successfully delivers the message to USERB, so GroupWise creates record #14 in MSG17.DB, which indicates that the message was delivered, and links record #14 to the master record, which is record #12. GroupWise also changes a value in USERA's user database to indicate that the delivery occurred and when it happened.
Here is a look at what happens when USERB opens the message from USERA: GroupWise creates a new record in MSG17.DB, indicating that USERB opened the message. GroupWise changes a value in the pointer record in USERA's user database, indicating that the item was opened and when it was opened.
Note If a GroupWise message is sent to a user on a different post office, it takes a specific route through file queues on its way to the destination post office. Understanding message flow through a GroupWise system is one of the most valuable troubleshooting tools you'll ever have. This scenario follows a message from one post office to another. The detail at the message store level is even more explicit than the detail previously described in this chapter.
Scenario #3: Message Flow Between Post Offices In this scenario, the messages between the post offices flow as described here: USERA is a user on PO1, which is a post office in DOMAIN1. USERB is a user on PO2, which is a post office in DOMAIN1. USERA's FID is 123. USERB's FID is 789. The MSGn.DB file for USERA is MSG17.DB. All users connect to their post offices in client/server access mode. PO1 is connected to DOMAIN1's message transfer agent (MTA) via MTP (TCP/IP) between the MTA and the post office agent (POA). PO2 is connected to DOMAIN1 via a UNC link.
Note We recommend that domain-to-PO connectivity be via TCP/IP; however, this scenario uses a UNC connection from a domain to a post office so that you can understand the message flow in case you are using a UNC connection.
The message store at PO1: USERA sends a message, with the subject "Test1". It contains a small message body and one attachment over 2KB. The byte size of the file is 93,812. The message is sent to USERB. Here's what happens: The POA on PO1 creates the following records in MSG17.DB: A master record, which is record #385 in MSG17.DB. The DRN (document record number), which is a unique identifier for the message 3827C415.FDE. The DRN for any GroupWise message can be viewed from the properties of a message. It will look much like this: Mail Envelope Properties (3827C415.FDE : 17 : 65002). Note The 3827C415.FDE is the DRN, the 17 is the message database that the users use, and 65002 is a number that uniquely identifies the user. Every sent message that this user sends will have 17:65002 in the Mail Envelope properties.
A message properties record, which is record #384 in MSG17.DB. A message body record, which is record #382 in MSG17.DB. An attachment record, which is record #383 in MSG17.DB. A BLOB file called 382761a5.000 for the attachment that is created in the PO1\OFFILES\FD62 directory. The size of the BLOB file is 48,004 bytes. GroupWise compresses and encrypts BLOB files, which is why the file size decreased.
The POA also creates a record in PO1\OFUSER\USER123.DB with a pointer to record #385. This user database pointer record contains the following additional information: The DRN for record #385 The date and time that the message was sent To whom the message was sent Other status-tracking information as appropriate (delivered, opened, and so on)
Now let's see what happens in the file queues at PO1. Because the message is destined for PO2, all records associated with the message having the DRN 3827C415.FDE are packed up into one file and placed in the PO1\WPCSIN\4 directory. The original name of the file is 482761a5.2l0. The file is 49,760 bytes. Because USERA sent the message with normal priority, it will travel through the 4 directory (where normal-priority mail messages always flow). The POA on PO1 transmits the file via TCP/IP to the MTA on its message transfer protocol (MTP) port. Now let's see what happens in the file queues at DOMAIN1. The MTA receives the message on port 7100 and writes the file into the DOMAIN1\MSLOCAL\GWINPROG\4 directory. As the file is being received, it's called XEF34B5F.000. When the file is completely received, the MTA renames the file to 00000859.5P5. The MTA uses what's called an MTP thread to receive the message. The MTA's MTP thread tickles the MTA's router thread (RTR) and notifies it about the message in the GWINPROG\4 directory. The router thread looks at the recipient post office for the message and determines that the recipient post office is PO2. Note The DOMAIN\MSLOCAL\GWINPROG\X directories are memory queues. This means that an MTA will fetch files from this directory only when it is prompted to by another subprocess of the MTA. These directories are scanned on startup or restart of the MTA, but that is the only time they get scanned. Sometimes, though, you might find files stuck in the GWINPROG\X directories. If this is the case, just put them back into the DOMAIN\WPCSIN\0 directory. If you find a file with an X at the beginning of the filename and it's been there for a long time, don't bother moving the file. It's a casualty of a bad transmission. Just delete the file.
The MTA's RTR thread puts the file in the DOMAIN1\MSLOCAL\MSHOLD\PO25B46 directory, which is the FID for PO2. Note Every GroupWise object has an FID, be it a post office, a domain, or a user. To determine the FID for a post office, view the post office with GroupWise diagnostics and look for the attribute File ID.
When in verbose mode, the GroupWise MTA will report the message DRN. In this case, the MTA reported the following: 00:24:36 RTR: DOMAIN1: 00000859 Priority 4 3827C415.FDE:17:65002 : Transfer to DOMAIN1.PO2:OFS
Now let's go to the file queues at PO2. The MTA's RTR thread copies the file to the PO2\WPCSOUT\OFS\4 directory. The name that it gives the file is 482769C4.2l0. The byte size of the file is 49,820. The size of the file increased a bit from when it was on PO1 because the route the message took to get to PO2 is appended to the message. Note The WPCSOUT\OFS directories are the input queues for the POA process. Every POA has an FID of OFS, so the input queue for the POA looks for work to do from the MTA in the WPCSOUT\POA'S-FID\X directory. The POA's FID is (or should always be) OFS. On rare occasions, the POA might have a different FID. If you discover this through GroupWise diagnostics, delete the POA and re-create it.
Here's what happens at the message store at PO2. The POA picks up the file in the PO2\WPCSOUT\OFS\4 directory on its scan cycle and processes the file. The POA then commits the message to the message store at PO2. The PO2 POA creates the following records in MSG17.DB: A master record, which is record #4 in MSG17.DB. The DRN for this master record is 3827C415.FDE, just as it was on PO1. When viewing the properties of the message, USERB sees the same DRN as the sender. Mail Envelope Properties (3827C415.FDE : 17 : 65002) A message properties record, which is record #3 in MSG17.DB. A message body record, which is record #1 in MSG17.DB. An attachment record, which is record #2 in MSG17.DB. A BLOB file called 382774cd.000 for the attachment that is created in the PO2\OFFILES\FD62 directory. The size of the BLOB file is 48,004 bytesthe same size as the original file. A status record, which is record #5 in MSG17.DB. The status record indicates that USERB received the message. This status record must be relayed back to PO1, which is coming up in a moment.
The PO2 POA creates a record in PO1\OFUSER\USER789.DB with a pointer to record #4. The USER database also indicates the following: Here's what happens in the file queues at PO2. After the POA at PO2 delivers the message to USERB, it creates a status message to be sent back to PO1. The status message is placed in the PO2\WPCSIN\5 directory. The name of the file is 582774CD.2l0. The file is 820 bytes. Note The WPCSIN directory structure is the input queue for the MTA. The MTA for DOMAIN1 is configured to talk to PO2 via a UNC connection, so the MTA will pick this file up. This is different from an MTP connection in that the POA pushes information from the PO\WPCSIN\X directory up to the MTA. The POA push method through MTP is preferred, however, because it is more efficient.
Here's what happens in the file queues at DOMAIN1. The MTA's RTR thread picks up the file from the PO2\WPCSIN\5 directory and places it in the DOMAIN\MSLOCAL\GWINPROG\5 directory. It then routes the file to the DOMAIN\MSLOCAL\MSHOLD\PO15B1E\5 directory. The name of the file is 0000085C.001, and it is 860 bytes. The MTA's router thread tickles the MTP thread and instructs the MTP thread to look in the MSLOCAL\MSHOLD\PO15B1E\5 directory for the file called 0000085C.001 to be processed. Note The MSLOCAL\MSHOLD queues are largely memory queues. This means that an MTA will fetch files from this directory only when it is given the file's specific name. The MSLOCAL\MSHOLD directories are scanned on startup or restart of the MTA.
The MTA's MTP thread transmits the status file to the POA at PO1. The POA's MTP thread (listening on port 7101) receives the status file into its WPCSOUT\OFS\5 directory. The name of the file is 582782F4.210, and it is 860 bytes. The POA picks up the file and creates record #390 in MSG17.DB, linking that record to record #385, which is the original master record for this message.
Note The last record used before the message was transmitted from PO1 to PO2 was #385. The reason the status record was #390 is that other records were written to the MSG17.DB file. GroupWise just picks the next available record number when writing a record into a message database.
Now you know what happens when messages are sent, which will help when troubleshooting message flow, or when trying to determine why you are seeing messages in a certain queue. Important Architectural Concepts from Scenario #3 The preceding section tracked a message as it moved between two post offices on the same domain, exposing most of the architectural methods involved in message delivery: Messages are either being submitted to a location or being sent out of a location. If the message is being submitted to a location by the MTA, it is placed in a WPCSOUT\Process-File-ID directory. This is the MTA's output queue. If the message is being sent out of a location, it is placed in the WPCSIN\X directory. This is the MTA's input queue. Every message will pass through one of the eight queue directories, numbered 07. Here are the purposes of these queues (another review from Chapter 4): 0: | Live, interactive request messages (busy searches, remote library queries) | 1: | Remote user update requests, shared folder, and shared address book replication messages | 2: | Administration updates and high-priority messages | 3: | Status messages from high-priority mail | 4: | Normal-priority messages | 5: | Status messages from normal-priority messages, mailbox/library maintenance requests | 6: | Low-priority messages | 7: | Status messages from low-priority messages |
When messages reach an MTA, the MTA receives the file into the MSLOCAL\GWINPROG directories and then places the file into the MSLOCAL\MSHOLD\Location-File-ID directory. The file is then either transmitted (MTP via TCP/IP) or placed (UNC connectivity) at the destination. The file is then placed in the directory that corresponds to the FID of the process designed to process the message. When a message is sent from one GroupWise post office to the next, the message will retain its DRN, no matter which post office it is sent to. If a message is sent to a gateway, the DRN is taken off by the gateway. When a message is sent to more than one GroupWise post office, it is written to the same numbered message database on every post officethis is determined by the sender's FID. Elements of a GroupWise message are broken into separate records. Fields of certain record types can exceed 2KB. If a field exceeds 2KB, it becomes its own BLOB file. All elements of a GroupWise message are transmitted in one file when sent from one location to the next.
This section was heavily based on the GroupWise post office message store and flow within the message store. Scenario #4: Message Flow Between Domains In this scenario, User1 on PO1 at DOMAIN1 sends a message to User2 on PO2 at DOMAIN2. Here's the file flow. This scenario follows this message all the way to PO2 and then follows the status message back to PO1. This scenario does not focus as much on records and databases as the previous scenario did. The next section focuses more heavily on message flow. The scenario is as follows: USER1 composes a low-priority message and sends it to USER2. The POA on PO1 creates a message transport file in the PO1\WPCSIN\6 directory. The POA at PO1 transmits the file from the PO1\WPCSIN\6 directory to the domain's MTA via TCP/IP, using port 7100. The DOMAIN1 MTA receives the file and, while receiving, places it in the DOMAIN1\MSLOCAL\GWINPROG\6 directory. After complete receipt, the DOMAIN1 MTA moves the file to the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID\6 directory. The DOMAIN1 MTA transmits the file from the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID\6 directory to DOMAIN2's MTA via TCP/IP, using port 7100. The DOMAIN2 MTA receives the file and, while receiving, places it in the DOMAIN2\MSLOCAL\GWINPROG\6 directory. After complete receipt, the DOMAIN2 MTA routes the file to the DOMAIN2\MSLOCAL\MSHOLD\PO2-FileID\6 directory. The MTP portion of the MTA picks up the file in the DOMAIN\MSLOCAL\MSHOLD\PO2-FileID\6 directory and transmits it via TCP/IP to the PO2 POA's MTP port 7101. The POA on PO2 receives the file and writes it directly into the PO2\WPCSOUT\OFS\6 directory. The POA processes the message and inserts it into the message store at PO2. The POA generates a status message and places it into the PO2\WPCSIN\7 directory. The POA transmits the file in the PO2\WPCSIN\7 directory up to the DOMAIN2 MTA at TCP/IP port 7100. The DOMAIN2 MTA receives the file into the DOMAIN2\MSLOCAL\GWINPROG\7 directory. The MTA moves the file to the DOMAIN2\MSOCAL\MSHOLD\DOMAIN1-FILEID\7 directory. The MTA transmits the file from the DOMAIN2\MSOCAL\MSHOLD\DOMAIN1-FILEID\7 directory to port 7100 on DOMAIN1's MTA. The DOMAIN1 MTA receives the file into its DOMAIN1\MSLOCAL\GWINPROG\7 directory. The DOMAIN1 MTA moves the file to the DOMAIN1\MSLOCAL\MSHOLD\PO1-FILEID\7 directory. The DOMAIN1 MTA transmits the file to port 7101 on the PO1 POA. The PO1 POA receives the file into the PO1\WPCSOUT\OFS\7 directory. The PO1 POA places the status record into the GroupWise message store on PO1.
As you can see, message flow is logical and predictable. Understanding message flow at this level is very helpful when troubleshooting GroupWise. Scenario #5: Message Flow Through the GroupWise Internet Agent (GWIA) In this scenario, USERA is on PO1 at DOMAIN1 and wants to send a message to joe@acme.com via the Internet. PO1 connects with DOMAIN1 via TCP/IP. DOMAIN1 connects with DOMAIN2 via UNC. The GWIA is located on DOMAIN2. Here is the file flow: The PO1 POA writes the appropriate item records to USERA's user database and assigned message database. Because the destination is not on PO1, the PO1 POA drops a transport file in the WPCSIN\4 directory. The PO1 POA transmits the file from the WPCSIN\4 directory at the post office to the DOMAIN1 MTA at the MTA's MTP port. The domain MTA receives the file and places it in the DOMAIN1\MSLOCAL\GWINPROG\4 directory. The domain MTA routes the file to the DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FileID directory. Note: You can determine a domain's file ID in a couple of ways. Perhaps the easiest way is by looking at the MTA's HTTP port and clicking Links. From there, you can click a particular link, and it will tell you what the hold queue directory is for the destination link. You can also go to the console for Domain1. Press F10, choose Configuration Status, highlight DOMAIN2, and press Enter. The Hold directory contains the domain file ID. Because DOMAIN1 has a UNC connection to DOMAIN2, it does not transmit the message to DOMAIN2 via TCP/IP. The DOMAIN1 MTA places the message in the DOMAIN2\WPCSIN\4 directory. The message is destined for the GWIA on DOMAIN2, so the file is moved to the DOMAIN2\MSLOCAL\MSHOLD\GWIA-FileID\4 directory by DOMAIN2's MTA. The MTA transmits the message to the GWIA via MTP on the GWIA's MTP port. The GWIA then places the message into the DOMAIN2\WPGATE\GWIA\WPCSOUT\GWIA-FileID\4 directory. The GWIA will convert the GroupWise message to ASCII and drop the converted file into the DOMAIN2\WPGATE\GWIA\SEND directory. This is the input queue for the GWIA's sending daemon. The GWIA generates a transferred status message to be sent back to USERA. The GWIA places the transferred status message in the DOMAIN2\WPGATE\GWIA\WPCSIN\5 directory. The GWIA then transmits the message to the MTA via TCP/IP on the MTA's MTP port. Also, after the GWIA's daemon transmits the message to the Internet recipient, it generates a conversation log about its transaction with the SMTP host on the Internet where the GWIA sent the message. That conversation log is kept in a file in the DOMAIN2\WPGATE\GWIA\SEND directory. The GWIA analyzes this file to see whether there is any reason to modify the status of the Internet message so that it says something beyond transferred. The DOMAIN2 MTA receives the status file from the GWIA into the DOMAIN2\MSLOCAL\GWINPROG\5 directory. The DOMAIN2 MTA tickles a RTR thread and notifies it about the file in the GWINPROG\5 directory. The RTR thread looks at the message and determines that the message is destined for DOMAIN1. The RTR thread places the message in the DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FileID directory. The DOMAIN2 MTA's RTR thread tickles the MTP thread and notifies it about the file in the DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FileID directory. The DOMAIN2 MTA transmits the file to the DOMAIN1 MTA on MTP port 7100. The DOMAIN1 MTA's MTP process receives the status message in its DOMAIN1\MSLOCAL\GWINPROG\5 directory. The DOMAIN1's MTA tickles a RTR thread and notifies it about the file in the DOMAIN1\MSLOCAL\GWINPROG\5 directory. The DOMAIN1 MTA's RTR thread routes the status message to the DOMAIN1\MSLOCAL\PO1-FileID directory. The DOMAIN1 MTA's RTR thread tickles the MTP thread and notifies it about the file in the DOMAIN1\MSLOCAL\PO1-FileID directory. The DOMAIN1 MTA's MTP thread transmits the status message to the PO1's POA on its MTP port. The POA at PO1 receives the status message in the PO1\WPCSOUT\OFS\5 directory. The POA at PO1 appends the status message to the message store at PO1.
This section was unique in that it showed message flow when a UNC path is used. A UNC path connection between domains or post offices is less efficient because a message must go through more queues, and because messages are picked up from their queue via a polling process. The method of polling queues isn't nearly as quick or efficient as the TCP/IP transfer method. A Simplified View of Message Flow Each of the previous three examples went into quite a bit of detail. This section outlines the file flow for the previous scenarios. Remember, the goal here is to reveal the GroupWise file flow system so that you will be able to troubleshoot problems with message delivery. Scenario #1: PO1 to PO2 in the Same Domain In this scenario, a user on PO1 sent a message to a user on PO2. Both PO1 and PO2 are in the same GroupWise domain. Message: The message transport file passed through each of the following directories in order as it proceeded from PO1 to PO2 for delivery: Status message: The status message transport file passed through each of the following directories as it proceeded from PO2 back to the sender's post office, PO1: Scenario #2: PO1.DOMAIN1 to PO2.DOMAIN2 In this scenario, a user on PO1 sent a message to a user on PO2. PO1 and PO2 exist in different domains. Message: The message transport file passed through each of the following directories as it proceeded from PO1 to PO2 for delivery: Status message: The status message transport file passed through each of the following directories as it proceeded from PO2 back to the sender's post office, PO1: Scenario #3: PO1.DOMAIN1 to GWIA.DOMAIN2 In this scenario, a user on PO1 sent a message to an Internet address. The GWIA resides on a different domain than the sender's post office. Message: The message transport file passed through each of the following directories as it proceeded from PO1 to the GWIA (the transmission of the message via SMTP and its ultimate delivery to the Internet recipient are not described here): PO1\WPCSIN\4 DOMAIN1\GWINPROG\4 DOMAIN1\MSLOCAL\MSHOLD\DOMAIN2-FID\4 DOMAIN2\GWINPROG\4 DOMAIN2\MSLOCAL\MSHOLD\GWIA-FID\4 DOMAIN2\WPGATE\GWIA\WPCSOUT\GWIA-FID\4
Status message: The status message transport file passed through each of the following directories as it proceeded from the GWIA back to the sender's post office, PO1. Keep in mind that this status message does not indicate that the message was delivered to the Internet recipientonly that the message was successfully transferred to the GWIA's SMTP daemon. These are the directories it proceeded through: DOMAIN2\WPGATE\GWIA\WPCSIN\5 DOMAIN2\MSLOCAL\GWINPROG\5 DOMAIN2\MSLOCAL\MSHOLD\DOMAIN1-FID\5 DOMAIN1\MSLOCAL\GWINPROG\5 DOMAIN1\MSLOCAL\MSHOLD\PO1-FID\5 PO1\WPCSOUT\OFS\5
You will probably want to bookmark this page. This section's explanation of message flow is something you can refer to if you need to troubleshoot message flow. |
