Pid Provider

Sistema Distribuído: Core + Upload - Gerenciamento de PIDs

Arquitetura do Sistema

O sistema SciELO possui uma arquitetura híbrida distribuída com:

• Core: Aplicação central única que gerencia o banco de PIDs consolidado
• Upload: N instâncias descentralizadas, uma por coleção SciELO nacional
• Sincronização: Registro local + sincronização com Core via API

Módulos Compartilhados

Componentes Comuns:

• pid_provider/models.py: Modelos de dados (PidProviderXML, XMLVersion, etc.)
• pid_provider/base_pid_provider.py: Lógica base de processamento de PIDs

Componentes Específicos:

• Upload: pid_provider/client.py - Cliente API para comunicação com Core
• Core: views.py - Endpoints REST para receber requisições das instâncias Upload

Fluxo de Operação

1. Recepção no Upload:

• Upload recebe XML de artigo científico
• Processa e registra PID localmente usando BasePidProvider
• Mantém registro local em PidProviderXML com status inicial

2. Sincronização com Core:

• PidProviderAPIClient empacota XML e metadados
• Envia via POST para endpoint /api/v2/pid/pid_provider/ do Core
• Core processa via PidProviderViewSet usando mesmo BasePidProvider

3. Tratamento de Conflitos:

• Se Core detecta PID v2 incorreto, Upload usa endpoint /fix_pid_v2/
• FixPidV2ViewSet corrige inconsistências entre sistemas
• Registro local do Upload é atualizado com dados do Core

Vantagens da Arquitetura

• Resiliência: Upload continua funcionando mesmo com Core indisponível
• Consistência: Core mantém visão unificada de todos os PIDs
• Autonomia: Cada coleção opera independentemente
• Sincronização: Dados locais são eventualmente consistentes com Core

O diagrama ilustra a arquitetura distribuída híbrida do sistema SciELO, destacando:

🔵 Pontos Chave da Arquitetura:

1. Distribuição Geográfica

• Múltiplas instâncias Upload (Brasil, Argentina, México, etc.)
• Core centralizado unificando todos os PIDs
• Processamento local com sincronização remota

2. Componentes Compartilhados

• models.py: Definições de banco idênticas em ambos sistemas
• base_pid_provider.py: Lógica de negócio unificada
• Garante consistência de processamento

3. Especialização por Sistema

• Upload: client.py para comunicação API
• Core: views.py para recepção de requisições
• Cada sistema otimizado para sua função

4. Fluxo de Resiliência

Processamento Local → Tentativa de Sync → Falha de Rede → Operação Continua

5. Correção de Conflitos

• Detecção automática de PID v2 incorreto
• Endpoint dedicado /fix_pid_v2/ para correções
• Sincronização bidirecional Upload ↔ Core

6. Benefícios Operacionais

• Alta Disponibilidade: Upload funciona offline
• Consistência Global: Core mantém visão unificada
• Escalabilidade: Adição fácil de novas coleções
• Integridade: Resolução automática de conflitos

Esta arquitetura permite que o SciELO opere globalmente com autonomia regional, mantendo consistência de dados e alta disponibilidade do serviço.

graph TD
    %% Upload Instances
    UPLOAD1[📤 Upload Brasil<br/>Instância SciELO BR]
    UPLOAD2[📤 Upload Argentina<br/>Instância SciELO AR]
    UPLOAD3[📤 Upload México<br/>Instância SciELO MX]
    UPLOADN[📤 Upload N<br/>Outras Coleções...]
    
    %% Core System
    CORE[🏛️ Core Central<br/>Sistema Unificado SciELO]
    
    %% Shared Components
    SHARED_MODELS[📊 Módulos Compartilhados<br/>pid_provider/models.py<br/>pid_provider/base_pid_provider.py]
    
    %% Upload Specific Components
    CLIENT[📡 Upload Específico<br/>pid_provider/client.py<br/>PidProviderAPIClient]
    
    %% Core Specific Components  
    VIEWS[🔌 Core Específico<br/>views.py<br/>PidProviderViewSet<br/>FixPidV2ViewSet]
    
    %% Workflow Steps
    XML_INPUT[📄 XML Input<br/>Artigo Científico]
    
    %% Local Processing
    LOCAL_PROCESS[⚙️ Processamento Local<br/>BasePidProvider.provide_pid_for_xml_with_pre<br/>Registro em PidProviderXML local]
    
    %% API Communication
    API_CALL[📡 Chamada API<br/>POST /api/v2/pid/pid_provider/<br/>XML + Metadados]
    
    %% Core Processing
    CORE_PROCESS[🏛️ Processamento Core<br/>PidProviderViewSet.create<br/>Mesmo BasePidProvider<br/>Registro consolidado]
    
    %% Conflict Resolution
    CONFLICT_CHECK{❓ Conflito<br/>PID v2?}
    FIX_PID[🔧 Correção PID<br/>POST /fix_pid_v2/<br/>FixPidV2ViewSet]
    
    %% Sync Back
    UPDATE_LOCAL[🔄 Atualização Local<br/>client.provide_pid_and_handle_incorrect_pid_v2<br/>Sincronização com Core]
    
    %% Database States
    LOCAL_DB[(🗄️ BD Local Upload<br/>PidProviderXML<br/>XMLVersion<br/>Registro autônomo)]
    
    CORE_DB[(🏛️ BD Central Core<br/>PidProviderXML consolidado<br/>Visão unificada<br/>Todos os PIDs)]
    
    %% Success/Error States
    SUCCESS[✅ Sucesso<br/>PID registrado localmente<br/>e sincronizado com Core]
    
    RESILIENCE[🛡️ Resiliência<br/>Upload continua operando<br/>mesmo com Core indisponível]
    
    %% Flow Connections - Input
    XML_INPUT --> UPLOAD1
    XML_INPUT --> UPLOAD2  
    XML_INPUT --> UPLOAD3
    XML_INPUT --> UPLOADN
    
    %% Shared Components
    SHARED_MODELS -.-> UPLOAD1
    SHARED_MODELS -.-> UPLOAD2  
    SHARED_MODELS -.-> UPLOAD3
    SHARED_MODELS -.-> UPLOADN
    SHARED_MODELS -.-> CORE
    
    %% Specific Components
    CLIENT -.-> UPLOAD1
    CLIENT -.-> UPLOAD2
    CLIENT -.-> UPLOAD3
    CLIENT -.-> UPLOADN
    VIEWS -.-> CORE
    
    %% Local Processing Flow
    UPLOAD1 --> LOCAL_PROCESS
    LOCAL_PROCESS --> LOCAL_DB
    LOCAL_PROCESS --> API_CALL
    
    %% API Communication
    API_CALL --> CORE
    CORE --> CORE_PROCESS
    CORE_PROCESS --> CORE_DB
    CORE_PROCESS --> CONFLICT_CHECK
    
    %% Conflict Resolution
    CONFLICT_CHECK -->|Sim| FIX_PID
    CONFLICT_CHECK -->|Não| UPDATE_LOCAL
    FIX_PID --> UPDATE_LOCAL
    
    %% Final Update
    UPDATE_LOCAL --> LOCAL_DB
    UPDATE_LOCAL --> SUCCESS
    
    %% Resilience Path
    API_CALL -.->|Falha de Rede| RESILIENCE
    RESILIENCE --> LOCAL_DB
    
    %% Multiple Upload Instances
    UPLOAD2 -.-> LOCAL_PROCESS
    UPLOAD3 -.-> LOCAL_PROCESS  
    UPLOADN -.-> LOCAL_PROCESS
    
    %% API Endpoints Labels
    API_ENDPOINTS[🔗 Endpoints Core<br/>POST /api/v2/pid/pid_provider/<br/>POST /api/v2/pid/fix_pid_v2/<br/>Authentication: Bearer Token]
    
    CORE -.-> API_ENDPOINTS
    API_CALL -.-> API_ENDPOINTS
    FIX_PID -.-> API_ENDPOINTS
    
    %% Architecture Benefits
    BENEFITS[💡 Benefícios da Arquitetura<br/>• Resiliência: Upload autônomo<br/>• Consistência: Core unificado<br/>• Escalabilidade: N instâncias<br/>• Sincronização: Eventual consistency]
    
    SUCCESS -.-> BENEFITS
    RESILIENCE -.-> BENEFITS
    
    %% Styling
    classDef upload fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef core fill:#fff3e0,stroke:#f57c00,stroke-width:3px
    classDef shared fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef process fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
    classDef api fill:#ffebee,stroke:#d32f2f,stroke-width:2px
    classDef database fill:#e0f2f1,stroke:#00695c,stroke-width:2px
    classDef decision fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    classDef success fill:#e8f5e8,stroke:#2e7d32,stroke-width:3px
    classDef info fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    
    class UPLOAD1,UPLOAD2,UPLOAD3,UPLOADN,CLIENT upload
    class CORE,VIEWS,CORE_PROCESS core
    class SHARED_MODELS shared
    class LOCAL_PROCESS,XML_INPUT process
    class API_CALL,FIX_PID,UPDATE_LOCAL,API_ENDPOINTS api
    class LOCAL_DB,CORE_DB database
    class CONFLICT_CHECK decision
    class SUCCESS,RESILIENCE success
    class BENEFITS,API_ENDPOINTS info

Loading