Tuesday, October 31, 2017

Explore Endeca Workbench Architecture and embedded applications


Explore Endeca Workbench - Apache Sling Web Console


Oracle Commerce 11.2

Workbench is an hybrid web application, housing the Experience Manager (XM), EAC console, Data sources (CAS crawls) etc., providing the bunch of capabilities for business users and also the content and system administrators to configure and administer the Endeca application. 

The Endeca workbench application is made up of other well known technologies and applications like Apache Sling, a framework for RESTful web-applications, Apache Jackrabbit, a content repository complying to the JCR API, Apache Felix, etc.,

In this blog we can have a look at the Apache Sling configurations and capabilities that are exposed and available for fine tuning.

Apache Sling

Simply put, Apache Sling is a framework for RESTful web applications, mapping HTTP request URLs to content resources based on the request's path, extension, etc.,
You can have a deep dive on Sling at the above link...

Apache Sling application exposes the configuration parameters, packaged bundles, exposed services, log support and other monitoring features through the Web Console.

Through the Endeca Workbench application, Apache Sling Web Console can be accessed, providing a gateway for controlling and monitoring many important Sling features.

Web console path:
http://<host>:<port>/<root_context>/system/console/

Console

The console exposes various capabilities and monitoring features like log support, configuration, installed packages / bundles, memory usage, exposed REST services etc., useful in maintaing and fine tuning the application

Sling Web Console
Apache Sling Web console

Sling Log Support

This screen can be used to control and manage the logging features of Sling, like error level, file rotation etc.,

Sling - Log Support

Configuration

The configuration tab exposes the capability to edit the configurations of various installed bundles (like webdav, etc.,) and other sling configurations like thread pool configurations and much more..



The below Sling Thread Pool configuration will help to fine tune the performance of the Sling module. You can tune threadpool configurations like Minimum and Maximum pool size, Keep Alive Time, priority of the threads, etc.,



Authenticator and RESTful services

In this tab you can review the various RESTful services that are exposed for authenticating services like login, session timeout, logout, etc.,

Services like publishStatus, sessionStatus as the name indicates expose useful services that can be used for any customization. 

Authenticator


Endeca - PublishStatus service response

Endeca - SessionStatus service response

Configuration Status

In the configruation status, various status of components can be reviewed like Memory usage etc.,
Importantly it exposes the Sling.properties file by which you can review the settings available in the file. 

Sling.properties

WebDAV

Apache Sling (JCR based Apache Jackrabbit) supports WebDAV protocal, Web Distributed Authoring and Versioning (a simple protocal based on HTTP, allowing users / clients to do content authoring operations remotely. For more, here).

In the context of Oracle Endeca Workbench, the Workbench application which stores the files in the configuration repository, files like cartridge XMLs, landing pages and other XM configuration files can be accessed directly using a WebDAV client like CyberDuck etc.,

Complete Sling WebDAV features can be referred here.

Installed bundles - For Example WebDav support

For complete WebDAV client setup, refer this nice article.

Saturday, October 28, 2017

What is STOMP...

STOMP - The Streaming (or Simple) Text Oriented Messaging Protocol


So, what is STOMP?

Simply put, its a Text Oriented protocol for messaging between two applications or through a message broker. 

Officially it goes, STOMP provides an inter-operable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.

STOMP is text-based and does not use binary protocols. It supports a range of core enterprise messaging features, such as authentication, messaging models like P2P & publish and subscribe, message acknowledgement, transactions, message headers & properties, etc.,

There are number of messaging protocols like AMQP, MQTT, etc., but STOMP stands out as one of the popular messaging protocols which is Text based. 

All leading Messaging brokers support STOMP protocol, for STOMP compliant message brokers refer here.

A nice comparison between leading messaging protocols like AMQP and STOMP, can be found in the following blog.


For further reading:



Sunday, October 8, 2017

Endeca Baseline Indexing Issue - Perl Script Error

Baseline Indexing Issue Fix - Perl script error

Can't locate strict.pm in @INC


Can't locate strict.pm in @INC (@INC contains: /tmp/original_perl_build_dir/lib/5.8.3/x86_64-linux /tmp/original_perl_build_dir/lib/5.8.3 /tmp/original_perl_build_dir/lib/site_perl/5.8.3/x86_64-linux /tmp/original_perl_build_dir/lib/site_perl/5.8.3 /tmp/original_perl_build_dir/lib/site_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Sometimes when Baseline or Partial indexing may fail while executing any utility scripts, with "Perl" script error, as above ( check the below screenshots for reference..) 





To fix this error, follow the below steps:

  1. Check if the PlatformServices are running in Endeca Server  (eg- using ps -ef | grep java )
  2. naviage to /opt/endeca/PlatformServices/11.2.0/tools/server/bin
  3. Execute ./shutdown.sh 
  4. navigate to /opt/endeca/PlatformServices/workspace/setup
  5. Execute the following command - source installer_sh.ini
  6. navigate back to /opt/endeca/PlatformServices/11.2.0/tools/server/bin
  7. Execute ./startup.sh
  8. Execute the indexing again, either from back-end or using dyn/admin page. 

References: ENDECA_CONF =  /opt/endeca/PlatformServices/workspace


Friday, October 6, 2017

Catalog Maintenance System - Manual process

Catalog Maintenance System 

Catalog Maintenance System - CMS, is a set of batch process and dynamic services that updates catalog, category and product relationships.

The service can be executed by various methods.


  1. Manual invocation
  2. Scheduled service
  3. Automatic invocation after project deployments


In this post, we can see how to manually invoke the CMS process. 

Step-by-step guide

  1. Login into dyn/admin of the server (http://<IP>:<port>/dyn/admin/)
  2. Goto Commerce adminstration page -> Basic Catalog Maintenance1.                                             http://<IP>:<port>/dyn/admin/atg/commerce/admin/en/maintenance/startService.jhtml?process=BasicMaintProcess
  3. Click on Start Process 
  4. The process should end without any errors  
  5. Execute Baseline Index



Tuesday, October 3, 2017

WSO2 - Registry setup

All WSO2 products are shipped with a built-in registry, supported by the H2 Database packaged with the product. Though its sufficient for many applications, its not recommended for Enterprise integration applications and Production environments.

In our case the ESB registry is mounted with WSO2 Governance Registry (GREG). The below steps can be used to change the ATOM based registry mount (default) with JDBC based mount.

The following example was implemented on the systems which had deployed resources and services, servicing other applications.

GREG

1. In GREG, replace WSO2_CARBON_DB in master-datasources.xml with JDBC details.

<datasource>
   <name>WSO2_CARBON_DB</name>
   <description>The datasource used for registry and user manager</description>
   <jndiConfig>
        <name>jdbc/WSO2CarbonDB</name>
   </jndiConfig>
   <definition type="RDBMS">
       <configuration>
           <url>jdbc:oracle:thin:@172.17.0.2:1521:XE</url>
           <username>USER</username>
           <password>USER1234</password>
           <driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName>
           <maxActive>50</maxActive>
           <maxWait>60000</maxWait>
           <testOnBorrow>true</testOnBorrow>
           <validationQuery>SELECT 1</validationQuery>
           <validationInterval>30000</validationInterval>
        </configuration>
   </definition>
</datasource>

2. Since we are using a ORACLE Database, copy the driver ojdbc6.jar to the following path
<PRODUCT_HOME>/repository/components/lib/

3. Back up the .CAR files and configurations and packages

4. The following command will create the necessary tables on the target Datasource configured in the above step.
sh wso2server.sh -Dsetup

Validate the following

1. Tables and DB objects are created in the DB
2. Whether data is populated
3. Old resource content are also available
4. Existing CAR files got deployed successfully

Console:

User management

1. Existing user got updated in DB
2. Create a new user and the same should be populated in the DB



In ESB 4.9.0


1. Update the <PRODUCT_HOME>/repository/conf/datasource/master-datasources.xml
Add the following configuration

<datasource>
   <name>WSO2_CARBON_DB_GREG</name>
   <description>The datasource used for registry and user manager</description>
   <jndiConfig>
        <name>jdbc/WSO2CarbonDB_GREG</name>
   </jndiConfig>
   <definition type="RDBMS">
       <configuration>
           <url>jdbc:oracle:thin:@172.17.0.2:1521:XE</url>
           <username>USER</username>
           <password>USER1234</password>
           <driverClassName>oracle.jdbc.driver.OracleDriver</driverClassName>
           <maxActive>50</maxActive>
           <maxWait>60000</maxWait>
           <testOnBorrow>true</testOnBorrow>
           <validationQuery>SELECT 1</validationQuery>
           <validationInterval>30000</validationInterval>
        </configuration>
   </definition>
</datasource>

2. Update the registry configuration

<PRODUCT_ HOME>/repository/conf/registry.xml

<dbConfig name="remote_registry">
      <dataSource>jdbc/WSO2CarbonDB_GREG</dataSource>
</dbConfig>

-- Specify the remote Governance Registry instance --

<remoteInstance url="https://172.17.0.6:9443/registry">
    <id>instanceid</id>
    <dbConfig>remote_registry</dbConfig>
    <cacheId>USER@jdbc:oracle:thin:@172.17.0.2:1521:XE</cacheId>
    <readOnly>false</readOnly>
    <enableCache>false</enableCache>
    <registryRoot>/</registryRoot>
</remoteInstance>

Mount configuration
    <mount path="/_system/governance" overwrite="true">
        <instanceId>governanceRegistryInstance</instanceId>
        <targetPath>/_system/governance</targetPath>
    </mount>

2. Copy the JDBC driver - ojdbc6.jar to /repository/components/lib/

3. Restart ESB

Validate the following

1. Logs have the successful mounting of remote registry




References:


https://docs.wso2.com/display/ESB490/Remote+Instance+and+Mount+Configuration+Details
https://docs.wso2.com/display/ESB490/Governance+Partition+in+a+Remote+Registry

Root password of a Docker container

Root User Privileges in a Docker Container Often we will come across situations where the default user setting in docker container will be n...