Batch PDF rendering for ECO packages in visualization module

PLM Oracle Agile PLM
, , , , , , , ,
1

We implemented an automated batch PDF rendering solution for ECO packages in Agile 9.3.5 that significantly reduced our approval cycle times. Previously, engineering had to manually generate PDF views of all affected CAD files before routing ECOs for approval, which created a bottleneck taking 2-4 hours per ECO package.

Our solution leverages the visualization module’s batch processing capabilities with workflow event triggers. When an ECO reaches ‘Ready for Review’ status, a Process Extension automatically queues all attached CAD files for PDF rendering. The visualization server processes them overnight, and the PDFs are attached to the ECO by morning. This eliminated the manual PDF generation step and improved our approval cycle time by 35%. The system maintains full document traceability - each PDF is version-stamped and linked to the source CAD file’s specific revision.

2

Great questions - let me provide comprehensive details on our implementation addressing all three key areas.

Batch PDF Rendering Implementation:

Our solution uses the Agile Visualization SDK integrated with a custom Process Extension. The architecture consists of three components:

  1. Workflow Event Trigger: When an ECO transitions to ‘Ready for Review’ status, the PX is invoked automatically. The trigger captures the ECO object and retrieves all attached CAD files from affected items.

  2. Rendering Queue Manager: The PX submits rendering jobs to the visualization server’s batch queue via the Visualization API. We implemented intelligent queuing:

    • Check current queue depth before submission
    • Priority scoring based on ECO urgency and due date
    • Batch size limits (max 30 files per ECO to prevent queue monopolization)
    • Retry logic for failed renderings (3 attempts with exponential backoff)

  3. Completion Handler: A separate PX monitors rendering job completion. When PDFs are ready, it attaches them to the ECO and sends notification to the approval team.

CAD Format Handling:

Raj, we process CATIA V5, SolidWorks, and Creo files primarily. The visualization server handles these formats reliably with proper CAD translators installed. Key considerations:

  • Format-specific settings: Each CAD format has optimized rendering parameters. CATIA assemblies use medium quality (balance between detail and file size), while SolidWorks parts use high quality.
  • Large assembly handling: Assemblies over 500 components are rendered with simplified representation to keep PDFs under 20MB.
  • Failure handling: About 2% of renderings fail (usually due to corrupted CAD files or missing references). The system flags these for manual review rather than blocking the ECO.
  • AutoCAD 2D files: These bypass the 3D rendering engine and use direct PDF conversion, which is faster and more reliable.

Workflow Event Triggers Configuration:

The PX is configured as a post-status-change event handler. Here’s the implementation approach:

// Pseudocode - Key implementation steps:

  1. Detect ECO status change to ‘Ready for Review’
  2. Query all affected items and their latest CAD file attachments
  3. Filter for supported CAD formats (CATIA, SolidWorks, Creo)
  4. Build rendering job request with metadata (ECO number, item number, revision)
  5. Submit to visualization queue API with priority flag
  6. Log job submission details for tracking
  7. Schedule completion check job for 12 hours later // See documentation: Agile Visualization SDK Guide Section 5.3

The workflow event is non-blocking - the ECO continues to ‘Ready for Review’ status immediately while rendering happens asynchronously in the background.

Document Traceability:

Linda, we implemented comprehensive traceability using Agile’s built-in attachment relationships plus custom attributes:

  1. Attachment Metadata: Each generated PDF includes custom attributes:

    • Source_CAD_File: Original CAD filename
    • Source_Revision: Specific CAD file revision
    • Rendering_Date: Timestamp of PDF generation
    • ECO_Number: Associated ECO
    • Rendering_Job_ID: Visualization server job ID

  2. Attachment Relationships: PDFs are attached to the ECO with relationship type ‘Rendered_Visualization’ (custom relationship we created). This distinguishes them from manually uploaded PDFs.

  3. Revision Linking: The PX creates a reference link between the PDF attachment and the specific CAD file revision in the Agile file manager. This ensures that even if the CAD file is revised later, the PDF remains linked to the correct historical revision.

  4. Audit Trail: Every rendering operation is logged in a custom audit table with: user who triggered the workflow, timestamp, CAD files processed, PDF generation results, and any errors. This satisfies ISO audit requirements.

  5. Version Stamping: PDFs include a header watermark showing: “Generated from [CAD filename] Rev [X] on [date] for ECO-[number]”. This provides visual traceability even when the PDF is printed or exported.

Storage and Performance Considerations:

Carlos raised important points about storage:

  • Storage Growth: We generate approximately 15GB of PDFs monthly. Our retention policy archives ECO PDFs to secondary storage after 2 years (ECOs in ‘Closed’ status for 24+ months).
  • File Size Optimization: The rendering engine compresses PDFs using medium-quality settings, keeping typical assembly PDFs under 10MB. We experimented with quality settings and found medium quality provides adequate detail for approval reviews while minimizing storage.
  • Archival Strategy: Archived PDFs are moved to a separate file vault with slower access times but lower storage costs. The Agile attachment record remains but points to the archive location.
  • Cleanup Process: PDFs for cancelled or obsolete ECOs are purged after 5 years per our document retention policy.

Performance Metrics:

After 8 months of production use:

  • Average rendering time: 6 minutes per CAD file
  • Queue wait time (average): 15 minutes
  • Success rate: 98%
  • Approval cycle time reduction: 35% (from 5.2 days to 3.4 days average)
  • Manual effort savings: 12 hours per week across the engineering team

Lessons Learned:

  1. Visualization Server Sizing: We initially underestimated server requirements. We upgraded from 4 to 8 CPU cores and doubled RAM to 32GB to handle peak loads.

  2. Network Bandwidth: Large CAD files (100MB+) caused network bottlenecks. We implemented file staging where CAD files are copied to the visualization server’s local storage before rendering.

  3. User Communication: Engineers initially complained about PDFs not being immediately available. We added status indicators on the ECO showing ‘Rendering in Progress’ with estimated completion time.

  4. Fallback Process: For urgent ECOs that can’t wait for overnight rendering, we provide a manual ‘Render Now’ button that prioritizes the job. This is used for about 10% of ECOs.

The implementation required about 120 hours of development and testing effort but has delivered significant ROI through time savings and improved process consistency. The key success factor was close integration between the workflow engine, visualization module, and robust error handling.

3

This is exactly what we need! How did you handle the visualization server capacity? We have concerns about queuing 50+ CAD files simultaneously and overwhelming the rendering engine. Did you implement any throttling or priority queuing?