App as Library

The module integration makes it possible to integrate a customer journey directly within the routing of a parent application. The NGX-PFE then takes over a child route within the app.

1. How to Setup the Module Integration

The generation of a module customer journey is quite similar to a standalone one. Follow these steps to integrate a customer journey as a module in an app:

1.1. Install and Setup the TALY Nx Packages

npm install --save-dev @allianz/taly-nx

or

yarn add --dev @allianz/taly-nx

1.2. Generate the Customer Journey as Module

Add the configuration files of the customer journey to a local folder. For example src/app/customer-journey/config/. The configuration files are identical to a standalone app.

Now add a new target (e.g., "generate-journey") to your project configuration that will take care of generating your customer journey:

{
  "generate-journey": {
    "executor": "@allianz/taly-nx:generate",
    "options": {
      "configDirectory": "src/app/customer-journey/config",
      "target": "module"
    }
  }
}

After that, generate the customer journey module using this new target:

npx nx run your-application:generate-journey

This will generate the customer journey as an Angular Module in a folder called generated next to the specified configDirectory folder. This Angular Module can be integrated directly in the routing of the parent app, see the next step.

💡 You can add the watch: true option to the target or pass the --watch flag to the nx run command to start the executor in watch mode to continuously regenerate your journey:

npx nx run your-application:generate-journey --watch

💡 If you don't want to or can't use the generate executor, you can use the generate-journey TALY CLI command to generate the journey. The command could look like this:

npx taly generate-journey --name=myCustomerJourney --target=module

1.3. Add the Module to the Routing of the Parent App

The generated customer journey provides an EntryModule in the entry.module.ts file. It can be imported at any point within the routing structure of the parent app.

For example:

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';

const routes: Routes = [
  {
    path: 'customerjourney',
    loadChildren: () =>
      import('./customer-journey/generated/entry.module').then((m) => m.EntryModule)
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes, { initialNavigation: 'enabled' })],
  exports: [RouterModule]
})
export class AppRoutingModule {}

The customerjourney child route is now taken over by the page flow engine with the customer journey. It is also lazy loaded.

The pfe documentation provides more details about the routing integration.

1.4. Further Setup of the Parent App

The parent app needs to ensure that all the dependencies, that are required by the customer journey are available. The generated folder of the module contains a package.json file that describes these dependencies. The dependencies from this file need to be made available in the parent app.

It might also be necessary to add some further setup. For example to setup the ndbx library in the app.

A checklist for the manual integration steps could look like this:

  • Add Dependencies
  • Ensure that the tsconfig contains:
{
  "compilerOptions": {
    "resolveJsonModule": true,
    "allowSyntheticDefaultImports": true
  }
}
  • Integrate the required assets of the customer journey
  • Ensure that required global modules are imported in the app.module.ts of the parent:
    • For example the BrowserAnimationsModule
  • Setup Localization
    • Angular localize
    • Including dayjs
  • ⚠️ The parent app is responsible for dealing with Authentication. The parent app needs to provide a log-in page/mechanism and needs to provide the HTTP interceptor to add the necessary HTTP Header(s) to the generated app's network requests.

After this the app can be started and the customer journey will be available in the separate route.

🧩 A full example setup can be found in the module-integration recipe.

Sharing environment data with a customer journey

The parent app can pass its environment configuration to the integrated journeys using the HOST_ENV_DATA injection token from @allianz/taly-common/module-integration.

import { HOST_ENV_DATA } from '@allianz/taly-common/module-integration';
import { environment } from '../environments/environment';

@NgModule({
  // ...
  providers: [
    {
      provide: HOST_ENV_DATA,
      useValue: environment
    }
  ]
  // ...
})
export class AppModule {}

The generated module will receive the value from that token, to obtain the general and the module-specific properties, in case there are any. For properties with the same name, the priority is the following, from top to bottom: property in the environment object of the generated module, module-specific property in the parent app, and general property in the parent app.

For example, considering the parent app has such an environment object:

export const environment = {
  production: true,
  BFF_BASE_URL: 'localhost:8888',
  firstJourney: {
    BFF_BASE_URL: 'localhost:1111'
  },
  secondJourney: {
    BFF_BASE_URL: 'localhost:2222'
  },
  thirdJourney: {
    // ...
  }
};

And the generated journeys have the following environment objects:

// firstJourney
export const environment = {
  BFF_BASE_URL: 'localhost:5555'
};
// secondJourney
export const environment = {
  // ...
};
// thirdJourney
export const environment = {
  // ...
};

The resulting environment object that each of the generated modules will see is:

// firstJourney
export const environment = {
  production: true,
  BFF_BASE_URL: 'localhost:5555'
};
// secondJourney
export const environment = {
  production: true,
  BFF_BASE_URL: 'localhost:2222'
};
// thirdJourney
export const environment = {
  production: true,
  BFF_BASE_URL: 'localhost:8888'
};

💡 The key used to set module-specific environment data in the parent app must match the project name of the generated module. When invoking the generate-journey CLI command, that value is provided via the --name option, while when running journey-src this corresponds to the value of the --project parameter. In both cases this matches the journey's project name in the project configuration file.

results matching ""

    No results matching ""