Part Status Reporting to Stratus
PypeServer connects to a Stratus web-service to automatically import parts into PypeServer. PypeServer also reports Part status back to Stratus. The Stratus status list (stages of work) can be customized, while PypeServer uses a fixed set of workflow stages. This document explains how PypeServer reports Part status back to Stratus as PypeServer as Parts move through to the final PypeServer stage of "Cut".
This document does not discuss the protocols or methods for connecting to Stratus, or how to use Stratus with PypeServer.
Contents
2 PypeServer Status Reporting Logic 3
2.1 When PypeServer Reports back 3
2.2 How PypeServer reports status for multiple Scheduled Parts attached to one Part. 3
3.1 Keep only one PypeServer "active" (not Scrapped) Scheduled Part per Stratus Part 4
3.2 Map the PypeServer "Scrapped" status to the earliest stage 4
4 Deleting Parts out of PypeServer 4
First the Stratus workflow stages must be mapped to PypeServer status stages so PypeServer knows what to report back when a Part's status changes. To do this PypeServer queries Stratus to get the customer defined list of workflow stages. Those stages are then mapped to the Part Status field in PypeServer. The Customer maintains this mapping, though PypeServer assists in initial configuration, and it typically does not require changing.
In PypeServer, in the Stratus Web-Service Configuration window, (Settings, Services Tab??Stratus), the status list from Straus is shown, and the mapping is made between the two systems by dragging the Stratus stages over the center column to associate them (map them) to the PypeServer status stages.
Note that the statuses in the blue rectangles are samples for demonstration purposes only. Each Stratus customer will define their own status list of workflow stages.
The following describe how and when PypeServer reports status changes back to Stratus. For this discussion all PypeServer Parts are assumed to be linked to Stratus Parts.
First, it's important to understand that a PypeServer "Part" contains the geometric design of the part, plus all the metadata about the part. PypeServer Parts have "Scheduled Parts" attached to them, which are effectively "work orders" for the Part. The three types of Parts (Stratus Parts, PypeServer Parts, and PypeServer Scheduled Parts) are shown here:
PypeServer only reports on Scheduled Parts (the items to be cut). Reporting occurs:
When a PypeServer Scheduled Part is created, or
When the Scheduled Part's status changes,
AND
The PypeServer status is mapped to a Stratus status.
PypeServer users can create more than one Scheduled Part per PypeServer Part. This makes sense in some PypeServer situations (such as creating multiple assemblies, multiple chiller run tubes, or segmented elbows). It usually does not make sense to have multiple Scheduled Parts when the Part is linked to a single Part in a Stratus model. If there are multiple scheduled parts, here are the rules that govern PypeServer status reporting:
Rule: If there are multiple Scheduled Parts for one PypeServer Part, PypeServer will report back the earliest stage status of all the Scheduled Parts. Here is the PypeServer status order:
Earliest Stage: Not Nested ?? Nested ?? On Machine ?? Cut ?? Scrapped :Latest Stage
For example, a PypeServer Part has these five Scheduled Parts,
one "Not Nested"
one "On Machine"
two "Cut",
one Scrapped
In this case if any Scheduled Part's status changes, then PypeServer would report back the earliest PypeServer status of "Not Nested".
Why report like this? This logic is meant to allow customers to make multiple copies of the same part. Stratus may elect to create functionality where they send PypeServer a Part (design) requiring (for example) four copies be cut. Or the operator may choose to make four parts of each because they are making four identical spools. PypeServer will only report the final "Cut" status only when all four of the Scheduled Parts are cut.
Important: After creation of Scheduled Parts from a sync with Stratus, it is the PypeServer user's responsibility to neither delete nor create more scheduled parts. The system will report only on what is in the PypeServer system, but it does not keep count or report Scheduled Part counts up to Stratus.
At the time of this writing, one Stratus part requires only one part in PypeServer. Therefore it is recommended that users have only one "active" (not Scrapped) Scheduled Part per Stratus Part. Recommended Part management:
It's OK to scrap a scheduled part, but if a user scraps a Scheduled Part, they should create another to replace it. The replacement part will automatically become the part that is reported back to Stratus.
Note that it is possible that customers may use Stratus in some way as to require multiple identical parts for multiple assemblies. The PypeServer user can support this by simply creating additional Scheduled Parts.
If a user scraps a Scheduled Part, (the status changes to "Scrapped") and that Part has no other Scheduled Parts that are not scrapped, then PypeServer will report the Scrapped status, which should map to some early Stratus stage (status) indicating that the part is not cut, not nested, etc. This will tell Stratus that the part is not completed. Typically the PypeServer user would also create a replacement part, which will then become the part being reported.
Users can delete parts already cut out of PypeServer. No status updates are sent back up to Stratus when Parts or Scheduled Parts are deleted. Some scenarios:
If you finish cutting a Part, and the Scheduled Part's status is "Cut" then that will have been reported back to Stratus and deleting it will not affect it's status in Stratus.
If you do not do anything with a Part after it comes down from Stratus, and delete it, then the part in Stratus will have a the status mapped to "Part is New" in PypeServer. This could be misleading in Stratus, so deleting an uncut part in PypeServer might require some cleanup in Stratus.