Mobile

What Customers wants  the most in their B2B Portals ?

What Customers wants the most in their B2B Portals ?

In a B2B portal, customers typically have specific expectations and requirements that revolve around improving their business processes, enhancing efficiency, and delivering a seamless experience. While the specific needs can vary depending on the industry and organization, here are some common features and functionalities that customers often prioritize in their B2B portals:

1. User-Friendly Interface: Customers expect an intuitive and easy-to-navigate interface that allows them to quickly find the information and tools they need. A clean and organized design with logical navigation helps enhance user experience.

2. Self-Service Capabilities: B2B customers often prefer self-service options that enable them to independently access product catalogs, place orders, track shipments, manage invoices, view order history, and handle other transactions without the need for manual intervention.

3. Personalization: Customers appreciate personalized experiences tailored to their specific needs. Customization options such as saved preferences, personalized recommendations, and relevant content based on their previous interactions can significantly enhance their satisfaction and efficiency.

4. Product Information and Catalog Management: Accurate and up-to-date product information, including descriptions, specifications, pricing, availability, and images, is crucial for B2B customers. Advanced search and filtering capabilities to quickly locate products within large catalogs are also essential.

5. Order Management and Tracking: Customers expect a robust order management system that allows them to create and manage orders, track order status in real-time, view order history, request quotes, and manage returns or exchanges easily.

6. Pricing and Contract Management: B2B customers often have specific pricing agreements, contracts, and negotiated discounts. The portal should provide visibility into contract terms, personalized pricing, volume discounts, and the ability to manage contract renewals and negotiations.

7. Inventory and Stock Availability: Real-time inventory visibility helps customers determine product availability, expected delivery times, backorders, and substitutes. This information allows them to make informed decisions and plan their procurement accordingly.

8. Collaboration and Communication Tools: B2B portals that offer collaboration features such as secure messaging, document sharing, and project management capabilities enable effective communication and collaboration between customers, suppliers, and partners.

9. Integration with Backend Systems: Integration with the customer’s ERP, CRM, or other backend systems ensures seamless data flow, reduces manual data entry, and provides real-time information across the organization’s ecosystem.

10. Responsive and Mobile-Friendly Design: With the growing use of mobile devices, customers expect B2B portals to be accessible and optimized for mobile use. Responsive design ensures a consistent experience across different devices.

It’s important to note that customer preferences may vary depending on the specific industry, company size, and target audience. Conducting customer research, gathering feedback, and continuously iterating on the portal’s features based on customer needs and expectations can lead to a more successful B2B portal implementation.

 

What Customers wants the most in their B2B Portals ? Read More »

Best Practices : When using React with Liferay DXP

Best Practices : When using React with Liferay DXP

React has been a popular platform which has been in demand now a days .

React is popular for several reasons, which have contributed to its widespread adoption among developers:

  1. Efficiency and Performance: React’s virtual DOM and efficient rendering algorithms make it highly performant. Component Reusability: React’s component-based architecture promotes reusability, allowing developers to create modular and independent components.
  2. Declarative Syntax: React uses a declarative syntax, which means developers describe what they want the UI to look like based on the current state.
  3. Large Ecosystem and Community: React has a thriving ecosystem with a wide range of libraries, tools, and resources available.
  4. React Native: React Native, built on top of React, allows developers to build mobile applications using JavaScript.
  5. Backed by Facebook and Community Trust: React was developed by Facebook, one of the world’s leading technology companies. Its association with a major industry player has instilled trust and confidence in React’s stability, reliability, and ongoing support. The backing of Facebook, along with the active community and continuous development, has solidified React’s position as a reliable and widely adopted technology.
  6. Ease of Learning and Adoption: React has a gentle learning curve compared to other frameworks, making it accessible to developers of various skill levels.
  7. Compatibility and Integration: React can be easily integrated with other libraries and frameworks.

Different ways of React and Liferay DXP Integration

Liferay provides 3 major ways how  React can be used with it . Following are the 3 ways

  1. Adapting the SPA into a single Widget
  2. Connecting the External React Apps with Liferay Headless APIs
  3. Extracting React components into different Liferay Widgets

Different scenarios when each integration way can be used

Following are the various scenarios when you can use each method of Integration.

  1. Adapting the SPA into a single Widget – This is the easiest way of integration of React Applications within Liferay DXP . Advantages of this method is that its very simple to integrate as we could add the external React application as a Remote app within a single widget of Liferay . Disadvantage being it may not be very Design friendly and Flexibility in terms of UI is reduced drastically
  2. Connecting the External React Apps with Liferay Headless APIs – This method of integration could be used when the requirement is to use an existing or external React application need to use the Liferay DXP platform and its features. For example we need an independent React application to use the Liferay User accounts data for login and then may be to read and updates the CMS data .
  3. Extracting React components into different Liferay Widgets – While this way may be the best way of integration in terms of Design and Flexibility but it may be a Labor Intensive process. In this process the react components can be divided logically into components which could be displayed individually in different widgets . This gives good presentability and the most preferred way for a complex applications .

 

Best Practices : When using React with Liferay DXP Read More »

Architecture and Solutioning Series: Persisting Bearer Token Using Liferay DXPs Expendo Table Feature

Architecture and Solutioning Series: Persisting Bearer Token Using Liferay DXPs Expendo Table Feature

Problem statement:

In this particular Scenario in the existing application the SSO was implemented using Microsoft OIDC Provider with Liferay DXP. At the time of login the ‘Microsoft OIDC provider’ generated a Bearer Token which was the identifier for the authenticated user .

This Bearer token was needed for all the further API calls to the API Gateway (which in turn called the external data source) . The API gateway used the Bearer Token to further validate the users identity and once validated it Processed the appropriate API response to the API call request .Hence we need to make it available throughout . We were not allowed to save the Token in Sessions because of security reasons.

Swim-lane diagram showing the OpenID Connect protocol's sign-in flow.

Reference : https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc

Conditions:

Bearer Token is Unique to every login .

Bearer Token is only available while OIDC call while login

Bearer Token should be available for the whole logged in period

Solution:

  1. We planned to extract the Bearer token  at the Login time Once at the while SSO event .
  2. To do so we used Liferay Post Login Action Feature to catch the event .
  3. We Extracted the TOKEN using logic local to the application .
  4. We decided to use Expendo Table feature and stored in KEY – VALUE where USERID was KEY and TOKEN was VALUE
  5. This KEY – VALUE was UNIQUE to each user and each login .



Following is the Example Code snippet for the same.

package com.login.event.post;
import com.liferay.expando.kernel.model.ExpandoTableConstants;
import com.liferay.expando.kernel.service.ExpandoValueLocalServiceUtil;
import com.liferay.portal.kernel.events.ActionException;
import com.liferay.portal.kernel.exception.PortalException; 
import com.liferay.portal.kernel.model.User; 
import com.liferay.portal.kernel.service.UserLocalServiceUtil;
import com.liferay.portal.kernel.events.LifecycleAction;
import com.liferay.portal.kernel.events.LifecycleEvent;
import org.osgi.service.component.annotations.Component;
/**
 * 
 * --------Author Details---------
 * Name:    YoungIT Consulting Services GmbH
 * Email:   [email protected]
 * Address: Fleethörn 7, 24103 Kiel, Germany
 * Phone:   +491514 5682025
 * --------Author Details---------
 * 
 */
@Component
(
immediate = true,
property = { "key=login.events.post" },
service = LifecycleAction.class
)
public class LoginPostAction implements LifecycleAction {
    @Override
    public void processLifecycleEvent(LifecycleEvent lifecycleEvent) throws ActionException {
        long userId = Long.parseLong(lifecycleEvent.getRequest().getUserPrincipal().toString());
        User user;
        try {
            user = UserLocalServiceUtil.getUser(userId);
            ExpandoValueLocalServiceUtil.addValue(user.getCompanyId(), User.class.getName(), ExpandoTableConstants.DEFAULT_TABLE_NAME,
                    "bearerToken", user.getPrimaryKey(), "==UPDATE_TOKEN_HERE==");
        } catch (PortalException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        System.out.println("login.event.pre=" + lifecycleEvent);
    }

Architecture and Solutioning Series: Persisting Bearer Token Using Liferay DXPs Expendo Table Feature Read More »

Understanding SSO – Part 1

Understanding SSO – Part 1

Understanding SSO concepts

To better understand SSO we first understand the evolution of authentication .

1) Simple authentication architecture (Without SSO)

 

  • There is a client (who is using the browser).
  • There is a server (which is basically a web server for the application) .
  • Client calls the login page and enters the Credentials .
  • Server authenticates the credentials again the DB .
  • Once authentication succeeds a session cookies is established between the client and server .

2) Generic SSO architecture

 

 

  1. The First call made to the web-application is redirected to the Identity provider (IdP) login page.
  2. User enters the credentials via browser and get back the token from the Identity provider (IdP).
  3. Token is sent to the Web application .
  4. Web app had a trust relationship with Idp or can have a key from Identity Provider (IdP) which is used to check the validity of the token.
  5. Once the validation succeeds the Web application puts a session cookie on the browser and the connection is established .

3) Understanding the Protocols

Now since we have understood the basic SSO mechanism , now is the time to get an understanding of the underlying authentication protocols used .

whenever we talk SSO we quite often hear about SAML , Open ID Connect , OAuth2 , OIDC etc.

Lets try to understand these

  • First thing first we need to understand that Open ID Connect and OIDC are the same protocol , so let’s not confusion over that .
  • Second important point is While OAuth 2.0 is an authorization protocol, OIDC is an identity authentication protocol .
  • Third point we need to know is The OpenID Connect (OIDC) protocol is built over the OAuth 2.0 protocol and helps authenticate users and convey information about them .
  • SAML is XML based and OIDC is JSON based protocol
  • SAML is quite old is Industry hence is quite matured but at the same time Complex .
  • SAML has highest security standard where as OIDC is moderate
  • OIDC is top in sense of user friendliness and implementations

So I hope you got the gist now i.e. SAML and OIDC can be used for identity authentication. These 2 protocols hence are also used for SSO implementations .

4) Differences between SAML and OIDC

 

 

Stay tuned to check more about SSO in our next article…

Understanding SSO – Part 1 Read More »

Moduler Approach in Liferay DXP

Moduler Approach in Liferay DXP

 

1) How moduler approach in Liferay helps creating customized solutions.

2) Liferay can be better explained as set of cubes where each cube is a different feature .

3) Customizing the vanilla (Default) Liferay Bundle by simply ADDING or REMOVING these cubes (Features).

4) Enabling/ disabling Multiple (OOB) security features as per customers need .( Example – Enabling SSO with NTLM, CAS, SiteMinder, OpenSSO, OpenID, Facebook)

5) Scaling the solution as per expected number of enduser (can be achieved using features like autoscaling in LIferay DXP Cloud ).

Link – https://lnkd.in/eWZHmtgc
#architect #security #cloud #Liferay #liferaydxp
#digital #experience  #liferayExperienceCloud #architecture  #design

 

Moduler Approach in Liferay DXP Read More »

Language
Scroll to Top