Integrating modules in a Salesforce lightning Architecture

ModulesLeave a Comment on Integrating modules in a Salesforce lightning Architecture

Integrating modules in a Salesforce lightning Architecture

In recent months I have had weekly wonderful Salesforce Lightning sessions together with great DPG media colleagues Walter Stolle, Pablo Sijbrants, Niels Keuning and Pieter Peers. That’s why we decided to set up any number of blogs, with this a first step in a serie. The well-known topic within IT Architecture and Domain Driven Design are Modules or Microfrontends that have been blogged about before and that is why I would like to share through this blog how a module or Microfrontend set up in a Domain Driven Design Architecture is integrated into a Salesforce Architecture. Little was written about this in Salesforce during my search and hence this blog. But only before we go into this may be useful to first have some definitions clear. How do I describe software architecture. For those who do not understand what a Domain Driven Design Architecture and module is I would like to refer to the already created blogs:…. And what does the Salesforce Architecture consist of, in particular what are the building blocks with which we will work in Salesforce Lightning, including Service Cloud where we will run our microfrontends/modules in. Now that we have somewhat of an overview of the available components and know what a module or a microfrontend is, I would like to zoom in on the considerations that have been made when designing and integrating a microfrontend/module. Finally, how we integrate the Microfrontend/ module into Salesforce with some code examples. Concluding with a number of FAQs.

What is the Salesforce software architecture?

Software Architecture

Software Architecture can in my point of view be defined and visualized as the structure behind a piece of software and logical interconnected software components that together fulfill a common goal speaks through common language which is often communicated as standards and is closely related to culture. General global standards have been attempted to some extent to lay down ISO standards (such as: https://en.wikipedia.org/wiki/ISO/IEC_42010) that are often outdated, but very rarely implemented in practice. In practice, organisational architectural standards are often no more than informal rules in support of an evolutionairy culture homogeneous.

The Salesforce Architecture

The Salesforce Architecture is built on top of modern industrial standards. In Salesforce, I am now 12 years on since the beginning of the Force.com platform, and which has now grown to be the largest counterpart of Microsoft Dynamics. In the beginning it existed as a mere CRM system in the Cloud with the underlying development platform Force.com that contained its own Eclipse plug-in. User management, lists, outgoing messages, Workflow rules, VisualForce, Standard Queues, Cases, Assignment rules, custom objects, s-controls, Triggers, Visual Force Pages, Components, Javascript, Templating, Approval processes, etc.

Recent Salesforce Development shift

If I can give my own interpretation to the current development of Salesforce then when Salesforce was more of an all-round CRM system in the Cloud, it now become much more fragmented and segmented into various specialties within the organization as Marketing Cloud, Sales Cloud, Service Cloud, Commerce Cloud, Community Cloud and various other Cloud solutions with a cross platform multi device

end to end focus where each org contains such an amount of standard functionality to accelerate the time to market and standard building blocks to connect the various mentioned orgs in the Cloud through open standards such as SOA, Platform As A Service, SAAS, XML, HTTP (S), SOAP, REST to promote the interoptability between the building blocks through standard and custom APIs. The following provides a simple representation of these so called orgs which is basically an organisational unit with a standard set of functionality and or customised functionality.

How did the Salesforce software landscape continue?

If I can give my own interpretation to the current development of Salesforce then when Salesforce was more of an all-round CRM system in the Cloud, it has now become much more fragmented and segmented into various specialties within the organization of Marketing Cloud, Sales Cloud, Service Cloud , Community Cloud and various other Cloud solutions with a cross platform multi device

Image result for service console salesforce
Service Console

end to end focus where each org contains such an amount of standard functionality to accelerate the time to market and standard building blocks to connect the various mentioned orgs in the Cloud through open standards such as SOA, Platform As A Service, SAAS, XML, HTTP (S), SOAP, REST to promote the interoptability between the building blocks through standard and custom APIs. The following provides a simple representation of these orgs.

Considerations of Modules in Salesforce Architecture?

What are the pros and cons? The benefits are diverse with as example the centralization of building blocks within the responsibilities of a domain and thus minimizing conceptual errors through staggered maintenance. An additional advantage is that modules can be reused, such as, for example, a module that is used for modifying the account-related data, which could be integrated into a self-service portal and customer system. There is no definitive implementation set or standard for a module. It is important to carefully consider what a module must meet from a technical point of view in order to integrate it into the various target systems. In principle, with HTML, CSS, Javascript and modern open source program libraries it is even more possible than in Salesforce Lightning with regard to refinement of the look and feel. For each environment it will therefore have to be carefully examined what the technical system requirements are for a module for the realization of a design. In a custom-made self-service portal, it will be obvious that more creativity is possible for the integration of a module. The technological implementation (c # or Java) is more scalable because the natural resources are larger. In the beginning, a small learning curve is required, but implementation will accelerate as time progresses and implementation of full stack resources will only accelerate implementation. In a CRM system such as Salesforce Lightning – Service Cloud, it is therefore necessary to look carefully in advance at what is possible to determine the design. With every architectural direction that is chosen, there will always be advantages and disadvantages. There are by definition no prescribed global standards, but there are some ISO standards, there is training, design methodology, UML, design patterns or the experience of the software architect.

What did I had to consider when designing and integrating Microfrontends/Modules?

When designing modules that can be integrated into Salesforce Lightning, various aspects need to be taken into account such as: authorization, do we use OAuth 2.0 when collecting the module for authorization via a Bearer token? When sending back an update, we can then go directly to the backend of the module or we must route through a client side scripting, about which there are various options in Salesforce Lightning or Aura, via a backend proxy in Salesforce or a custom proxy outside Salesforce or do we authorise using an authentication server which caches the authorization tokens such as OneLogin and otherwise a cloud environment such as AWS. The responsive Salesforce Lightning – Service Cloud is component driven, pluggable and managed by nature, regular Javascript is stripped from a Lightning Web Component which is then possible in the client side scripting event model of Lightning Web Component and or else just Javascript on a Classic page. But also not to forget the performance because if the backend systems are not yet optimal in terms of loading time, then in the perception of the logged-in user of the module, Salesforce Lightning will seem to be the delayer. An answer to this is to improve the speed of the subsystems and to apply caching in an intermediate layer. How is communication set up between to the backend systems – REST services? Asynchronous communication is obvious better for a greater disconnection between the subscystems. In addition, there are numerous aspects to consider and, of course, in addition to the technical evaluation, the most important consideration is the organization / context.

Integrating Modules in Salesforce

Conceptual model – Microfrontend/Module architecture

Integrating the Microfrontend/module in Salesforce Lightning

What does the module look like in practice? If you finally know, then everything is simple. In the Salesforce Lightning App – I embed a standard object for loading a VisualForce (Salesforce Classic) page for which the permissions are set accessible for the appropriate user profiles.

Visualforce

Seen from the browser, this object is integrated within an IFrame because I refer to another page within the same Salesforce domain within the Salesforce Lightning Service Console App so that authorization is not required here. The VisualForce page refers to its own Apex backend and this backend makes an HTTPS GET request with supplied security headers to the Module to be purchased. The example below illustrates this.

Apex

The retrieved HTML is then rendered on the VisualForce page within the Service Console App and thus visible in the browser of the logged-in agent. This method can also largely be standardized. The URL can be configurable and within the Service Console App it is possible to provide parameters on components so that the technical functionality becomes generic. Then also an update request to the modules service by means of an HTML form post or a Javascript Post and JQuery otherwise. If a VisualForce page is injected from the backend into an OAuth Bearer token that is located in the server side UserInfo object as being the user session, Javascript client side can post a variable to a backend in SalesForce Lightning by reading out a variable can route to a REST service without this REST service being known in the loaded html code of the agent’s browser, and then display the response and display an interpreted result in the module within the Service Console App and then load it in the client’s browser. It is also possible to take the Salesforce look and feel possible by giving a theme called Salesforce. The CSS layout can be copied from a Salesforce page and integrated into the Module in a standard layout. This allows all modules to use the same layout. You see, the end result is relatively simple in the end, but it is mostly about the path from an unauthorized iframe, various meetings and the search for possibilities and then a creative and accepted solution for a cross-border organization up to the formation of new standards, rules and agreements for the associated group.

Micrfrontend/Module component dragged in the app
Microfrontend/Module – change account status
Microfrontend/Module – revoke subscription
Microfrontend/Module – subscription & invoices

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top