Peppol Ap Admin Applet

Overview

The Peppol AP Admin Applet is the console for operating BigLedger’s own Peppol Access Point, not for a customer’s own Peppol traffic. Where the My Peppol Admin Applet is a tenant looking at its own outgoing and incoming documents, this applet is the access point looking at everything the network delivers to it — the inbox queue that every inbound AS4 message lands in, the history of what was delivered, the tenant-company receiver mappings that decide which customer a document is handed to, and the PINT Malaysia testbed used to prove conformance to OpenPeppol and MDEC.

It is an operations and accreditation tool. It creates no accounting entries, moves no stock, and has no document of its own that can be finalised or voided.

Where it fits

Screens and menus

The Registered Companies grid starts empty: its tenant code defaults to peppolap — the access point’s own tenant, which normally has no mappings of its own — and only fills in once a tenant is chosen from the dropdown.

Two things in the navigation do not do what their labels suggest. The Testbed parent entry (peppol-testbed) is a grouping node with no route of its own, so only its two children are reachable. And the Personalization menu lists a Field Settings item pointing at field-settings, which is not a child route of personalization — selecting it falls through to the applet’s 404 redirect (menu-items.ts vs app.routing.ts, commit 5f24872).

Inside the Inbox Queue listing there is an advanced-search box, but its onSearch handler is empty and the search model it is given is internalSalesOrderSearchModel, copied from the Sales Order applet. Typing in it has no effect. Submit / Export / Withdraw buttons appear in the template as commented-out markup on both the listing and the edit screen; they do not render.

Screenshots needed

No screenshots exist for this applet. A capture session should take: the Inbox Queue listing with rows; the Inbox Queue Details read-only tab; the Registered Companies listing; the Validation Test listing; Validation Test → upload ZIP; the Checking grid showing VALID and INVALID rows with an error message; and the Sending Test input form with the Test Name dropdown open. Because every row on these screens is a real trading party’s identifier, captures must come from a scratch tenant or be redacted before publishing.

Configuration

Before you can use it

Applet settings

There are no working applet settings. The classification is applet-local (the applet defines its own FieldConfigurationComponent rather than importing the shared one from blg-shared-utilities), and both local screens are inert:

• Settings → Field Settings renders eight slide toggles — Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project — with no formControlName, no form group and a SAVE button with no click handler. These are the labels of a sales-document settings screen and have nothing to do with Peppol. No exposed control found (routes and settings components checked at commit 5f24872).
• Settings → Default Selection and Personalization → Default Selection offer a Default Branch and a Default Location dropdown, and write DEFAULT_BRANCH / DEFAULT_LOCATION into an APPLET_SETTINGS extension object. Both components are routed directly in app.routing.ts, so their @Input() appletSettings$ and @Output() save are never bound: appletContainer is undefined when a dropdown changes, and the SAVE button emits to nothing.

Neither key is read anywhere in the applet — a repo-wide grep for DEFAULT_BRANCH, DEFAULT_LOCATION, APPLET_SETTINGS and appletSettings at commit 5f24872 returns only the two settings components themselves. Nothing on any screen changes when they are set.

Settings in other applets that control this applet

Feature visibility / permissions

No client-side permission definitions are seeded for peppolApAdminApplet (0 rows in bl_applet_client_side_perm_dfn, checked 2026-09-14), and the applet reads no HIDE_* / SHOW_* keys, so the Feature Visibility screen has nothing to gate. Access is decided entirely server-side, per endpoint, from MyPeppolPermissions:

A role with none of these opens the applet and sees empty grids rather than an authorisation error.

Fields

Inbox Queue / Inbox History → Details — every control is readonly; this is a viewer, not a form.

Registered Companies → Details — also entirely readonly: Tenant Code, Tenant Comp Peppol ID, Company Name, Company Code, Created Date, Updated Date.

Validation Test → Create

Sending Test → Create

Checking grid (Validation Test → open a test → open an uploaded ZIP): No., File Name, File Size, File Format, Validation Status, Validation Error, Error Message, User Error Message, Created Date, Updated Date — one row per XML file found in the ZIP (bl_ppl_ap_validation_test_file_zip_helper).

Lifecycle and effects

This is a master-data and operations applet. It has no server document type, no amount or quantity signum, no journal and no stock processor; nothing here is finalised or voided.

Receiving — what happens to an inbound document

1. An AS4 message arrives. PeppolIncomingSBDHandlerSPI.handleIncomingSBD parses the Standard Business Document and calls MyPeppolReceivingInboxService.insertIntoPplApInboxQueue, which writes one bl_ppl_ap_inbox_queue row in the access point’s database, then queues PplApInboxQueueProcessor with ExecutionStrategy.RUN_NOW.
2. PplApInboxQueueProcessor.processEvent copies the queue row into bl_ppl_ap_inbox_doc_hdr (bl_ppl_ap_inbox_doc_hdr.fromBl_ppl_ap_inbox_queue) — this is the permanent access-point record shown in Inbox History.
3. It then reads bl_ppl_ap_tnt_comp_receiver_mapping by the message’s receiver Peppol ID (PeppolApTntCompReceiverMappingUow.getByCompanyPeppolId). For every mapping found it opens that tenant’s database, creates a bl_ppl_from_peppol_doc_hdr_queue row from the inbox document header, and queues FromPeppolDocHdrQueueProcessor inside that tenant.
4. Finally it permanently deletes the bl_ppl_ap_inbox_queue row (deletePermanent).

Two consequences follow directly, and they are the two facts an operator needs. Inbox Queue is transient — under normal operation it is empty, because rows are deleted microseconds after they are written; a row sitting in it means the processor has not run. And a receiver ID with no mapping is not an error — the loop simply finds nothing to iterate, the inbox document header is still written, and the message is silently not delivered to any tenant.

Registration — how a mapping appears

Registered Companies is written by PplApParticipantRegistrationService.insertIntoCompRcvrMapping, which copies the tenant GUID, tenant code, company GUID and participant ID from a bl_ppl_ap_participant_registration_hdr when a registration succeeds. The applet only reads the table.

Validation Test — what “Run Checking” actually checks

Run Checking calls GET …/ppl/ap/validation-test-file-helper/run-checking/{zip_hdr_guid}/backoffice-ep, which runs PeppolApValidationTestFileZipHelperService.validateAndUpdateZipHelper over every file extracted from the ZIP. For each file:

• the document type is inferred from the file name — a name containing invoice selects the invoice rules, a name containing creditnote the credit-note rules, anything else yields an empty type;
• the XML is validated against the PINT UBL schematron for that type (peppol/<doctype>/PINT-UBL-validation-preprocessed.sch) using the Ph schematron engine;
• it is validated a second time against the Malaysian jurisdiction rules (peppol/pint-my/1.0.0/xslt/billing/PINT-jurisdiction-aligned-rules.xslt), whose failed assertions are collected from the SVRL output;
• one assertion is deliberately dropped before the verdict — [ibr-119]-A time MUST be formatted hh:mm:ss with optional fractional seconds .sss and time zone expression (ibt-168).;
• if nothing remains, validation_status is set to VALID and error_message cleared; otherwise INVALID with the collected texts. The row’s updated_date is stamped either way.

Revalidate on a single file posts the XML to …/validate-document-one-by-one/backoffice-ep?docType=… and returns either the failure texts or the single token THIS_DOCUMENTS_IS_VALID.

Uploading a ZIP dispatches uploadAttachmentsInit, which calls PeppolAPTestbedValidationTestZipHdrService.addAttachment against the open validation test’s GUID. The success toast reads “Upload Image Successful” — a label inherited from the applet this screen was cloned from. Delete and download effects exist in the same file but are commented out, so the delete and download buttons on the uploaded-file screen dispatch actions nothing handles.

Sending — Send Only Valid XML and the per-file Send are described under Troubleshooting; at commit 5f24872 they call a URL the backend does not serve.

Related applets

• My Peppol Admin Applet — the tenant-side counterpart. Registrations made there create the receiver mappings listed here, and documents routed from here surface there under External Reception.
• My E-Invoice Admin Applet — the parallel LHDN pipeline; it shares the mandatory-field check but not this applet’s data.
• Organisation Applet — holds the company Peppol status and participant IDs that a registration is built from.

Troubleshooting

Related documentation

• PEPPOL Configuration Guide
• E-Invoice module