Skip to content

Migrating from transactional-message-library to limepgk-transactional-message-library

limepgk-transactional-message-library is the next generation TRAML but for, reasons, we chose to do a new package instead of a 2.0. TRAML is widely used and to be able to upgrade to a 2.0 it would require an update of all the consuming code and config at once. With this approach it's possible to move one TRAML email flow at a time or only add new ones.

Info

If the solution already has application config for the old TRAML package the new TRAML will default to that config. However, the new whitelist and override settings wont work unless the new config is in place as well.

Event-handler config is no longer supported - the config must be migrated to application_config for TRAML to find the configuration.

It is safe to use both packages at the same time, but some things have of course changed for the new package.

Things that Have Changed

  • We did work with the interface for TRAML so your code needs to be somewhat altered to new module names and class names.
  • We got rid of the event-handler so you now get a response back from Lime Marketing with the id of the email - you know its been queued for sending.
  • Since the event-handler is no longer used, it's up to the consumer to spawn a task to use TRAML asynchronously. Use cases would be when multiple (more than 5) emails should be sent and a user is waiting for a response in the application. It's likely the context already is a task or event-handler.
  • Only application_config is supported. If you have config in the the event_handler config that needs to be moved to the application_config.
  • We changed the structure of the application_config (however we try search for API info in the old config). To utilize the new whitelist/override features you need to move over to the new configuration.
  • SMS now supports merge codes just as emails.
  • TRAML now supports sending plain text content. You can send only plain text content or use text content as fallback for the HTML content.
  • Better configuration for testing with whitelisted dry run recipients and the possibility to override the recipient.
Back to top