Skip to content

Operations and smoke tests

What SEPE requires

SEPE does not “log into Moodle”. It requires the training centre to publish a tracking web service over HTTPS that matches the ProveedorCentroTFWS contract (Annex V of Order TMS/369/2019). SEPE systems call your URL and your platform answers.

That contract defines six SOAP 1.1 operations. They are not plugin extras: they are what the regulation asks for. local_sepe implements the provider side: it publishes the WSDL and handles those calls. Authentication details, the electronic office application and IAE registration are separate; this page is only the technical tracking piece.

Authentication

Every call: SOAP 1.1, HTTPS, WS-Security UsernameToken (PasswordText). Fixed user SEPE and the password defined by the centre (the same one you declare in the official application). Wrong user/password → SOAP Fault, no Moodle data. Details: plugin fields.

The six SOAP operations

Quick overview:

Operation Role
crearCentro Create/update the centre record on the service.
obtenerDatosCentro Returns that record (codes, URLs, contact).
crearAccion Registers a training action for tracking.
obtenerListaAcciones Lists action identifiers.
obtenerAccion Full action plus tracking (participants, results…).
eliminarAccion Removes an action from tracking.

crearCentro

SEPE (or the official test kit) pushes the centre identity fields: origin, code, name, platform URL, tracking URL, phone and email. The service stores them as the “who you are” record for tracking.

The official kit often uses origin 20 and code 9999999999. In production those codes are assigned by the competent body for your expediente; in local_sepe you can also keep the record in plugin settings.

obtenerDatosCentro

Asks for that record again: “who are you?”. Used to check that what your system holds matches expectations (name, URLs, codes, contact).

crearAccion

Sends a training action (SEPE identifier, dates, situation, specialty, and so on) so you register it on the platform for tracking. In Moodle you can link it to a course to enrich participants and grades.

obtenerListaAcciones

Returns the list of identifiers (ORIGEN_ACCION + CODIGO_ACCION) held by the service. The official kit checks that this list matches the actions it just created (including creation order).

obtenerAccion

Detail for one action. This is usually where tracking lives: participants, assessment, and so on. If the action is linked to a Moodle course, local_sepe can supply enrolments and grades from the campus.

eliminarAccion

Deletes an action from tracking. The official kit uses it at the end of the battery; in production you use it when that action must leave the service.

Typical flow (official kit)

SEPE’s ProvCentTFVal JAR exercises the contract roughly in this order:

  1. obtenerDatosCentro with a wrong password → must fail cleanly (Fault / rejection).
  2. obtenerDatosCentro with correct credentials → identity aligned with the sample XML.
  3. crearCentro → record 20 / 9999999999 (kit demo XML).
  4. Empty list → several crearAccion calls → matching list → obtenerAccion → eliminarAccion.

That validates the web service. It does not replace IAE registration or the centre’s administrative accreditation/inscription.

Smoke test

A smoke test is the smallest check that the connector “starts”: not a full audit and not the complete official kit.

  1. WSDL returns XML over HTTPS.
  2. obtenerDatosCentro with UsernameToken returns return code 0.
  3. obtenerAccion for a known action returns code 0.
  4. If a course is linked, participants and final grades appear (demo: Ana 85, María 91, Luis 72).

Demo action: origin 20, code 201428001000000000000000000001.

On the demo campus the official ProvCentTFVal kit has also been run with all OK (0 KO). See the product landing.

Note

Demo codes illustrate format only. Production CODIGO_CENTRO, CODIGO_ACCION and specialty codes are assigned by SEPE / the competent body for your expediente.