🛠️
Opencity Italia
Sviluppatori e partner tecnologici
Sviluppatori e partner tecnologici
  • Introduzione
  • Architettura
    • Pattern: microservizi
    • Pattern: event sourcing
    • Vista generale
  • Standard e convenzioni
    • Standard della piattaforma
    • Microservizi
  • Roadmap
  • Integrazioni
    • Integrazione Widget servizio (FormIO)
    • Integrazioni con il flusso delle pratiche
      • API ReST
      • Webhooks
    • Modello di integrazione con l'area personale
    • Integrazione con Intermediari di pagamento PagoPA
      • Requisiti per l'integrazione
      • Il Pagamento
        • Versione 1.0
        • Versione 2.0
      • Schema di Funzionamento
      • Configurazione dei pagamenti
        • API v1
        • API v2
      • Un pagamento in dettaglio
      • Gli stati di un pagamento
      • Processo di sviluppo
      • Implementazione di un proxy
    • Integrazione con Protocollo Informatico
      • Requisiti per l'integrazione
      • Documento digitale
        • Esempio documento con allegati non protocollato
        • Esempio documento con allegati protocollato
        • Esempio documento con campo retry_meta prodotto dal protocol proxy
        • Esempio documento con campo retry_meta modificato dal sistema di retry
        • Usecase: Il Documento originato dalle pratiche dai servizi digitali
        • Stati del documento
      • Architettura del sistema di protocollazione
      • WorkFlow sistema di protocollazione
        • Configurazione tenant e servizi
      • Protocol Proxy: Specifiche Implementative
      • Processo di sviluppo
    • Integrazioni con il Sito Istituzionale
    • Single Sign-On
      • SSO mediante oAuth2
      • SSO mediante JWT
    • Processi asincroni (job)
      • Importazione dovuti
    • Integrazione di un servizio di terze parti protetto da autenticazione
      • Esempio con GovWay
  • 👩‍💻Sviluppo
    • Multilingua
    • Temi grafici
Powered by GitBook
LogoLogo

Opencity Labs

  • Sito web
  • Product page

Developers Italia

  • Sito web
  • Area personale e Servizi Digitali

Documentazione Opencity Italia

On this page
  • Test delle chiamate SOAP/REST dell'intermediario
  • Test in ambiente locale
  • Test pre-deploy
  • Test in ambiente QA

Was this helpful?

Export as PDF
  1. Integrazioni
  2. Integrazione con Intermediari di pagamento PagoPA

Processo di sviluppo

Test delle chiamate SOAP/REST dell'intermediario

Le API fornite nella documentazione dell'intermediario vengono generalmente testate in prima battuta via Postman/Insomnia nel caso di chiamate REST o via SoapUI nel caso di chiamate SOAP

Test in ambiente locale

A seguito dei test delle chiamate, si procede con l'implementazione del microservizio. Per testarlo localmente fare riferimento al seguente docker-compose.yml

version: '2'

services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.0.0
    hostname: zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000

  kafka:
    image: confluentinc/cp-kafka:7.0.0
    hostname: kafka
    depends_on:
      - zookeeper
    ports:
      - "29092:29092"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: 'zookeeper:2181'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_CREATE_TOPICS: "applications,payments_cache"

  kafka-ui:
    image: provectuslabs/kafka-ui:latest
    ports:
      - "8080:8080"
    depends_on:
      - kafka
    environment:
      KAFKA_CLUSTERS_0_NAME: local
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
      # KAFKA_CLUSTERS_0_ZOOKEEPER: zookeeper:2181
      KAFKA_CLUSTERS_0_KSQLDBSERVER: ksqldb-server:8088

  topic-init:
    image: lorello/alpine-bash:1.4.0    
    depends_on:      
      - kafka    
    volumes:      
      - ./init.d:/data    
    command:      
      - /bin/bash      
      - -c      
      - |          
          wait-for-it kafka:9092          
          kaf config add-cluster local -b kafka:9092 && \          
          kaf config use-cluster local          
          set -ex          
          for I in /data/payment*.json; do            
            echo "Importing $$I"            
            cat $$I | jq -c | kaf produce payments          
          done

  # la configurazione varia in base al proxy da implementare
  iris-proxy:
    build:
      context: .
    ports:
      - "8000:8000"
    environment:
      CANCEL_PAYMENT: "false"
      KAFKA_TOPIC_NAME: "payments"
      KAFKA_BOOTSTRAP_SERVERS: "kafka:9092"
      KAFKA_GROUP_ID: "iris_payment_proxy"
      IRIS_OTF_PAYMENT_URL: "https://apistage.regione.toscana.it/C01/ComunicazionePosizioniDebitorieOTF/v3/IdpAllineamentoPendenzeEnteOTF"
      IRIS_IUV_URL: "https://iristest.rete.toscana.it/IdpBillerNdpServices/GenerazioneIUVService"
      IRIS_OUTCOME_URL: "https://apistage.regione.toscana.it/C01/InvioNotificaPagamentoEsito/v3/IdpInformativaPagamento.Esito"
      IRIS_VERIFY_URL: "https://apistage.regione.toscana.it/C01/VerificaStatoPagamento/v3/IdpVerificaStatoPagamento"
      IRIS_NOTICE_URL: "https://iristest.rete.toscana.it/IdpBillerNdpServices/GenerazioneAvvisiService"
      BASE_PATH_CONFIG: "sdc-payments/iris/tenants/"
      BASE_PATH_EVENT: "sdc-payments/iris/payments/"
      STORAGE_TYPE: "MINIO"
      STORAGE_KEY: "AKIAIOSFODNN7EXAMPLE"
      STORAGE_SECRET: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
      STORAGE_BUCKET_NAME: "payments"
      STORAGE_ENDPOINT: "minio:9000"
    depends_on:
      - createbuckets
      - kafka

  # storage dove vengono salvate le configurazioni del tenant, del servizio e lo stato dei vari pagamenti
  minio:
    image: minio/minio
    command: server /data --console-address ":9001"
    restart: unless-stopped
    volumes:
      - ./bucket:/data
    ports:
      - 9000:9000
      - 9001:9001
    environment:
      MINIO_ACCESS_KEY: AKIAIOSFODNN7EXAMPLE
      MINIO_SECRET_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  createbuckets:
    image: minio/mc
    depends_on:
      - minio
    entrypoint: >
        /bin/sh -c "
        while ! /usr/bin/mc config host add minio http://minio:9000 AKIAIOSFODNN7EXAMPLE wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY;
        do echo 'Wait minio to startup...' && sleep 0.1; done;
        /usr/bin/mc mb minio/payments;
        /usr/bin/mc policy set public minio/payments;
        exit 0;
        "

Test pre-deploy

Se si sta facendo il deploy di un nuovo microservizio per la prima volta o si sta aggiungendo una nuova API o una nuova pagina a una interfaccia esistente, è necessario aggiungere alcuni controlli di qualità minima prima del rilascio.

Controlli

  • Test flusso standard

    • Inserire la configurazione del tenant

    • Inserire la configurazione del servizio

    • Inserire un esempio di pagamento in stato CREATION_PENDING nel topic payments e verificare che venga correttamente creato il debito

      • Chiamare l'API /offline-payment/{id} e verificare che venga scaricato correttamente l'avviso di pagamento cartaceo

      • Chiamare l'API /online-payment/{id} e verificare che si venga rediretti al portale di pagamento

      • Una volta arrivati in fondo al pagamento online, verificare che premendo il bottone "Torna alla Home" venga chiamata correttamente l'API /landing/{id}

      • Chiamare l'API /update/{id} e verificare che venga correttamente controllato lo stato del pagamento ed eventualmente aggiornato e prodotto un evento sul topic payments

      • Chiamare l'API /receipt/{id} e verificare che, a pagamento avvenuto, venga scaricata correttamente la ricevuta telematica

      • Inserire un esempio di pagamento in stato PAYMENT_PENDING che è già stato processato precedentemente dal proxy e verificare che venga ignorato

      • Inserire un esempio di pagamento in stato PAYMENT_PENDING che non è già stato processato precedentemente dal proxy e per cui esiste una configurazione sullo storage, e verificare che venga salvato correttamente sullo storage (caso importazione dovuti)

  • Test flusso di errore

    • Modificare la configurazione del servizio in modo che sia errata (mettendo ad esempio credenziali errate)

    • Inserire un esempio di pagamento in stato CREATION_PENDING nel topic payments e verificare che, a seguito del fallimento, venga prodotto un evento in stato CREATION_FAILED nel topic payments

Test in ambiente QA

Si potrà accedere come utente SPID utilizzando l'utente AGID TEST DEMO.

Si potrà accedere come admin per eventualmente modificare il servizio di test e la relativa configurazione di pagamento

Si potrà accedere come operatore per testare pagamenti posticipati, i quali richiedono la presa in carico della pratica e l'approvazione di quest'ultima affinchè l'utente possa procedere con il pagamento.

PreviousGli stati di un pagamentoNextImplementazione di un proxy

Last updated 1 year ago

Was this helpful?

Test automatici delle API nella CI (usare , un esempio di utilizzo e un esempio di integrazione nelle CI)

I pagamenti sono testabili sul nostro ambiente di qa: .

hurl
qui
qui
https://servizi.comune-qa.bugliano.pi.it/