Posts Tagged ‘in’


Many a time, while working with Fatwire, we face the problem “CONTENT SERVER TIMEOUT ERROR“.  This problem will be annoying for us if we are working on the ADVANCED/ DASH UI. Check the below screen.

When a session error occurs, any unsaved changes are lost. All other content is saved and can be accessed and reviewed. To gain access to the system, you will need to login again. This is quite annoying.

This is due to the default setting given in FATWIRE’s FUTURETENSE.INI file for the Content Sever’s Timeout activity.

The default timeout for Content Server is 900 Seconds (900/60 = 15 mins)

The solution for getting out of this issue, at least for our specified amount of time) is to hack the FUTURETENSE.INI file.

Open the FUTURETENSE.INI file with PROPERTYEDITOR or normal text editor.

You will be able to find a property called  “cs.timeout”, and a default value assigned to it as “900″. It will look as follows:

cs.timeout=900

Where, 900 is the time set in SECONDS. Since 900/60 = 15 mins, the CS will be timedout every 15 minutes.

Hence, set the time as per which your wish. For example, if you need to set an hour as the default value for timeout activity, then set “3600” (as 3600/60 = 60 mins = 1 hour) as the value instead of “900“. It should look as follows:

cs.timeout=3600

Restart the Content server, for the changes to take effect.

The issue will be resolved.


In this topic, we are going to discuss the CREATION OF USERS IN FATWIRE. To create a user in Fatwire, you need to login with ADMIN Credentials. Users can be created in Fatwire using ADVANCED UI, and the WEM UI. We are going to learn how to create the users in ADVANCED UI of FATWIRE.

CREATION OF USERS IN FATWIRE:

1. Login to the ADVANCED  UI with Admin credentials.

2. Go to the ADMIN tab of the Advanced UI.

3. Expand “CONTENT SERVER MANAGEMENT TOOLS“. After expanding this, you will be able to see SITE, ELEMENT, ACLs, USER, etc.

4. Double click on USER. The following screen appears. In this screen, as shown below, we can MODIFY USERS, ADD USERS, DELETE USERS, MODIFY USER ATTRIBUTES.

5. Enter a name for the user in the ENTER USER NAME field. This name will be the login username for the new user.

6. Click on ADD USER radio button.

7. Click on the OK button. The following screen appears.

8. Assign the ACCESS PRIVILEGES for the user, as required.

9. Enter the PASSWORD, and re enter the same in RE-ENTER PASSWORD field.

10. Click on the ADD button.

That’s it.. A NEW USER IS CREATED IN FATWIRE.


Dynamic Publishing is the process of publishing the content (assets) to some other machine/destination. This Dynamic Publishing is of two types.

1. Mirror to Server : Mirror to Server is the method used to copy database rows to remote dynamic server

2. Real time Publishing : Real time Publishing is the method used to copy assets to remote dynamic server.

Out of these both, Mirror to Server is the one which is used mostly. Mirror to Server is built with the Content Server Mirror API to copy approved assets from the Content Server database on one system to the Content Server database on another system.

CREATION OF DYNAMIC PUBLISH DESTINATION:

The following steps are involved in the creation of a DYNAMIC PUBLISHING DESTINATION:

  • Login to the Advanced user interface.
  • Go to the admin tab of the tree.
  • Expand PUBLISHING -> DESTINATIONS.
  • Click on ADD NEW. The following screen appears:

  • In the “DELIVERY TYPE” drop down, select “MIRROR TO SERVER: Copy database rows to remote dynamic server”.
  • Enter a name for the publishing destination in NAME field
  • In the “DESTINATION ADDRESS” field, enter the name of the server, its port, followed by “/cs/”. For example, if  http://samplenode.com:8080/cs/Xcelerate/LoginPage.html  is the page which you use for logging into the advanced UI (URL of Remote Server), then the Destination address would look like this http://samplenodecom:8080/cs/
  • Enter the user name in “REMOTE USER” field.
  • Enter the password in “REMOTE PASSWORD” field.
  • Select the roles which approve the assets for publishing to this location.
  • Select the roles which can publish to this destination.
  • Select the sites for which this destination will be available.
  • Click on ADD NEW DESTINATION button in the bottom.

In this way, the Dynamic Publishing destination can be created.

Once the dynamic destination has been created, we need to check whether the destination is working properly or not. This can be known by observing the GREEN BULB image seen as shown in the image below. If a RED BULB image is shown, then there is some problem in connecting to the destination, like network issues, remote server might be down, licensing issues of the remote server for fatwire, VPN connectivity issues, etc. If any of the above issues arise, you need to consult the Fatwire / System Administrator of your company.

In this way, the Mirror to Server destination needs to be created and configured.

The rest of the APPROVAL, STATUS, PUBLISHING process is same as Static Publishing.


CACHING:

Caching is one of the most powerful techniques of Fatwire. An efficient caching system improves the performance of the overall system performance, by reducing the un-necessary overload to the Content server, and as well as the web server.

1. The Content server caches the pages that available in the CS system.

2. The Co-Resident Satellite server provides a second level of caching for the CS.

3. The Remote Satellite server provides another level of caching, so that the content can be closer to the intended audience.

Double – Buffered Caching:

When assets are updated and published, the Content Server and Satellite Server caches are automatically flushed and updated in the following order:

  • Content providers publish updated assets to the delivery system. CacheManager checks the cache tracking tables to see which cached items are affected by the updatedassets.
  • CacheManager flushes the outdated Pages from the Content Server cache, then reloads the Content Server cache with the updated Pages.
  • CacheManager flushes the outdated items from the Satellite Server cache. As visitors come to the web site and request a page P1, the Satellite Server searches to see if page P1 is in its cache. Because P1 is not in the Satellite Server cache, the request is passed
    on to Content Server.
  • The Satellite Server system’s cache is filled with an updated version of page P1, taken from the Content Server cache. The updated page is served to the requestors. If pageP1 were requested again, the page would be served from the Satellite Server cache.

Hence, this Caching system involves both Content Server Caching and Satellite server Caching.


In our previous posts, we have seen how to work with Static Publishing. In this post, we will see how to work with Dynamic Publishing.

DYNAMIC PUBLISHING, also known as MIRROR TO SERVER PUBLISHING method, is one of the important Publishing methodologies of Fatwire. It is built with the Content Server Mirror API to copy approved assets from the Content Server database on one system to the Content Server database on another system.

HOW IT WORKS:

The following image explains how the Mirror to Server publishing works in simple.

To be more precise,

1. When the Dynamic Publishing is done, the Local content server (on which the main database, file structure, etc are there) mirrors,i.e, copies the entire file structure to the remote server (the machine which hosts the site).

2. The user requests a page.

3. The request will be received by the server (i.e, the mirrored remote CS Server).

4. The CS dynamically generates the pagelets and pages, and delivers it to the webserver.

5. The webserver then delivers it to the end user who has requested the page.


The term PAGE constitutes a very important concept in FATWIRE.

There are a few terminologies in Fatwire related to Page, such as PAGE, PAGELET , PAGE NAME, PAGE ASSET.

Really… they are confusing. At least, I’m very much confused with these terminologies in the beginning. We will discuss the basic differences between these terminologies, so that we will get some clear cut idea, and we will know when to use which term.

1. PAGELET: A Pagelet is the result of an HTTP request. It is a piece of a rendered page. Its one among several pagelets that are rendered and displayed in a browser window. It has an associated element file, and that element has logic to generate this Pagelet.  A pagelet can be cached in the Content Server and Satellite Server page caches.

2. PAGE:  A Page is nothing but the result of an HTTP request. It is the one which is displayed in a browser window. Sometimes, a page is created by compiling several pagelets into one final, displayed or rendered page. It has an associated element file, and that element has logic to generate this page. A page can be cached in the Content Server and Satellite Server  page caches.

3. PAGE NAME: This is the complete name given to the page. For example, if Full is the name of a page, and if its type is Article , and if it is in the site Sample, the following will be the PAGE NAME : Sample/Article/Full.

4. PAGE ASSET: A page asset is the one which simply act as containers for the actual content. These containers are arranged in the SITEPLAN tab of the TREE to facilitate the ease of navigation.You associate other content and other assets with these PAGE ASSETS and then you publish them.


In my previous post, we have seen the creation of Static Publishing destination. In this post, and if required in the upcoming posts, we will discuss on how to work with this static publishing.

Static Publishing or Export to Disk Publishing, as quoted by the Fatwire Developer guide, “It renders your approved assets into static HTML files, using the template elements assigned to them to format them. An administrator or automated process then copies those files to your delivery system using FTP or another file transfer method.”

The Static Publishing is mainly used when the Basic Asset Model is used. While using the Flex Asset model, it rarely makes sense to use this Static Publishing methodology.

APPROVING THE ASSETS:

After the asset is created (lets take a PAGE asset here) , and a default template is assigned, we need to APPROVE the asset for making it available for PUBLISH.

To approve an asset, click on INSPECT action item of the asset (a Page here). Then click on MORE drop down list, and then click on “APPROVE FOR PUBLISH”. Check the below screen for the same.

image

Now, The next step to proceed with is to select the Publishing destination(If not created earlier, check out this link for creation of Static Publishing Destination). Select the appropriate publishing destination, if you have created more than one. Then click on the Approve button. Check the below screen for the same.

image

If the asset has any dependencies, those dependencies have to be approved first, before approving this asset.

That’s it.. The asset is Approved.

SETTING STATUS OF ASSETS:

If the assets are published directly, with out setting a specified file name, they will be exported with the ASSET’S ID by default. To avoid that, we need to specify a user friendly name. The STATUS screen helps us in setting a user friendly name for the asset, path for the asset (under the exported directory), and a starting point for the asset.

For setting the status, click on STATUS option of the MORE drop down menu. Then the following screen appears. Click on the “SPECIFY PATH/FILENAME, START POINTS” link in the appropriate publishing destination.

image

The next screen is the place where we need to set the above discussed (Path, File name, Starting points).

  1. Specify the Path and filename.
  2. If the asset needs to be published, it needs to be a starting point.  For example, if Page is a starting point, then the all the images, css, etc will automatically be exported by the page.
  3. Select the template and the wrapper page.
  4. Click on Save.

Check the below screen for the same.

image

PUBLISHING THE ASSETS:

Now, the final thing to do is to publish the assets. Click on the PUBLISHING option in the top of the work area. The following screen appears. Select the appropriate publishing destination. Check the below screen for the same.

image

The following screen appears next.  In that, we need to click on PUBLISH button.

image

To make sure that the files are exported correctly, we need to go to the export location, and check whether they are exported properly or not.

image

In this way, the  assets are exported successfully to the specified location.

This is STATIC PUBLISHING or EXPORT TO DISK PUBLISHING.

Stay tuned for more posts…


The STATIC Publishing method, other wise called as EXPORT TO DISK publishing method is a best option, especially when we want to export the files to the file system on the same machine on which the content server is residing. It exports the rendered html files (or any other files that are approved) to the location specified by the user. For example, if we want to export the html, css, js, etc files to an application server residing on the same machine as the content server, we should follow the Static Publishing method. In this topic, we are going to discuss how we should create a static destination, and how to publish (export) the files.

CREATION OF STATIC PUBLISH DESTINATION:

The following steps are involved in the creation of a STATIC PUBLISHING DESTINATION:

  • Login to the Advanced user interface.
  • Go to the admin tab of the tree.
  • Expand PUBLISHING -> DESTINATIONS.
  • Click on ADD NEW. The following screen appears:

image

  • In the “DELIVERY TYPE” drop down, select “EXPORT TO DISK: EXPORT WEB FILES TO DISK”.
  • Enter a name for the publishing destination in NAME field
  • The BASE DIRECTORY is the directory into which the files will be exported. For Jump Start kit, the following is the default location into which the files will be exported: <Drive>:\FatWire\JSK\7.5Patch5\ContentServer\7.5.5\export. If we give a name, a new directory will be created under the export folder specified above.
  • Select the roles which approve the assets for publishing to this location.
  • Select the roles which can publish to this destination.
  • Select the sites for which this destination will be available.
  • Click on ADD NEW DESTINATION button in the bottom.

That’s it, the publishing destination is created for Static Publishing.

In the next few posts, we are going to know how to work this Static Publishing.


When we create a site in alfresco share, and start inviting users to the site, the following error will be displayed “0 invites sent, 1 failure”.  This message leaves us to a bit of frustration, after creating sites, users, and when thinking of inviting users to the sites. This article gives the resolution for such a type of error message.

This error occurs because, the Outbound E-mail Configuration has not been set in alfresco-global.properties file. The quick turnaround for this issue would be to add a few lines of code to the alfresco-global.properties file, and add another file outboundSMTP-context.xml, if it doesn’t already exist.

Add the following to alfresco-global.properties file:

//Add to the end of alfresco-global.properties file
# Email settings mail.host=smtp.1and1.com mail.port=465 mail.protocol=smtps mail.username=XXX mail.password=XXX mail.encoding=UTF-8    mail.smtps.auth=true mail.smtps.starttls.enable=true
//END

If a file named outboundSMTP-context.xml doesn’t exist in C:\Alfresco\tomcat\webapps\alfresco\WEB-INF\classes\alfresco\subsystems\email\OutboundSMTP folder, then add the following file and name it as outboundSMTP-context.xml

//  <bean id="mailService">          <property name="host">              <value>${mail.host}</value>          </property>          <property name="port">             <value>${mail.port}</value>         </property>       <property name="protocol">         <value>${mail.protocol}</value>      </property>          <property name="username">              <value>${mail.username}</value>           </property>         <property name="password">              <value>${mail.password}</value>         </property>          <property name="defaultEncoding">             <value>${mail.encoding}</value>         </property>       <property name="javaMailProperties">          <props>               <prop key="mail.smtps.auth">${mail.smtps.auth}</prop>             <prop key="mail.smtps.starttls.enable">${mail.smtps.starttls.enable}</prop>          <prop key="mail.smtp.socketFactory.port">${mail.smtp.socketFactory.port}</prop>          <prop key="mail.smtp.socketFactory.class">${mail.smtp.socketFactory.class}</prop>           <prop key="mail.smtp.socketFactory.fallback">${mail.smtp.socketFactory.fallback}</prop>          </props>      </property>     </bean>

Now, restart alfresco and try inviting users. After inviting the users in share, it should display the following message “1 invites sent, 0 failure”.


The sites which are created in Fatwire can be listed using the tag  publication:list. In this article, we are going to display the list of sites created in Fatwire content server.

Following is the code piece:

<%@ taglib prefix="publication" uri="futuretense_cs/publication.tld" %>

//This library helps in the usage of the publication tag

//To retrieve the list of the sites, we are going to use the following code snippet
<publication:list list="mysites"/>

//Now, to display the sites, the following code snippet is used. We are going to display the sites using the listloop and listget tags:
<ics:listloop listname="mysites">
	    ID OF SITE: <ics:listget listname="mysites" fieldname="id"/>,
	    SITENAME :<ics:listget listname="mysites" fieldname="name"/>
</ics:listloop>