import { Observable } from 'rxjs'; import { ContactCenter, ContactCenterEntities, ImportResult } from './types/cc-import'; import * as i0 from "@angular/core"; export declare class CcImportService { private readonly api; private readonly dcpApi; /** * Answer everything from `mock/cc-import.mock.ts` instead of calling the backend. * * Note this is all-or-nothing: with it off, the contact-center list, the entity * overview and the import all hit real endpoints. Compatibility scoring is the * exception - see {@link resolveCompatibility}. */ useMockData: boolean; setToken(token: string): void; setHost(host: string): void; /** Base URL of the dcp host, which serves the UCCX application list. */ setDcpHost(dcpHost: string): void; /** * Every UCCX contact center Tuki can import. * * A "contact center" is a UCCX application. The list comes from the dcp * application cache; whether each one has already been imported is joined on from * the per-AEF-script call-flow migration states. */ fetchContactCenters(customerId: number): Observable; /** * Application-centric entity breakdown: everything Tuki will create on import. * * Note this only ever returns entities the backend has actually linked to the * application. Where that linkage is missing the groups come back empty rather * than padded with unrelated entities of the right type. */ fetchContactCenterEntities(customerId: number, contactCenter: ContactCenter): Observable; /** * Kicks off the UCCX -> Webex Contact Center import of one contact center, as a * single migration unit: every entity of the application goes in one request. * * The endpoint is synchronous and answers with an XLSX tracker rather than a job * id - execution and progress tracking are defined in a separate ticket. * * @param siteId required by the backend when a Resource Group is in scope. * @param locationId required by the backend when a Trigger is in scope. */ importContactCenter(customerId: number, applicationId: string, siteId?: string, locationId?: string): Observable; /** * Every UCCX entity belonging to one application, gathered across the batches. * * UCCX batches hold one entity type each, so this reads them all and keeps the * items whose `applicationName` matches. The narrowing is done here rather than * through the endpoint's own `applicationName` param because that param answers * `[]` on dev2 even for items that plainly carry the name. */ private fetchApplicationItems; /** The items endpoint nests items one level; older responses come back flat. */ private flattenItems; /** The same entity can be carried by more than one batch. */ private dedupeItems; private groupEntities; private toContactCenters; /** UCCX wraps the backing script as `SCRIPT[Foo.aef]`; the widget shows `Foo.aef`. */ private toScriptName; /** * Whether Tuki has already imported this contact center. * * The application record carries its own `migrationStatus`, but it is null * throughout dev2, so this falls back to the per-AEF-script call-flow state. */ private resolveMigrationState; /** * Turns an AEF compatibility score into a status. * * The scoring API does not exist yet - the AEF step mapping is still a pending * input on the ticket - so when the backend sends no score every contact center * falls back to "requires review": the status that offers both destinations and * claims nothing about compatibility we have not actually measured. * * Once the backend returns `compatibilityScore`, the thresholds below take over * with no further change here. */ private resolveCompatibility; private asArray; static ɵfac: i0.ɵɵFactoryDeclaration; static ɵprov: i0.ɵɵInjectableDeclaration; }