You can use “com.adobe.granite.workflow.status.WorkflowStatus” API to check the WF status of the payload.
Eg:
WorkflowStatus wfState = <payload object>.adaptTo(WorkflowStatus.class);
boolean status=false;
status = wfState.isInRunningWorkflow(true);
Here is the piece of code which you can use for HTTP Authentication while connecting to CQ url:
final String login ="admin";
final String password ="admin";
Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication (login, password.toCharArray());
}
});
String webPage ="http://localhost:8502/etc/workflow/models/translation?path=test";
URL url = new URL(webPage);
URLConnection urlConnection = url.openConnection();
The followig properties are always present in a bundle event object:
The following properties are always present in a service event object:
Ref: http://felix.apache.org/site/apache-felix-event-admin.html
For example, How to disable/remove ‘Activate’ or ‘Deactivate’ option to the specific user/group.
Solution:
1. Go to the CQ useradmin
2. Select the user/group and disable read permissions under (/libs/wcm/core/content/siteadmin/actions).
Here is the piece of code to impersonate the session:
@Reference
SlingRepository repo;
Session adminSession = repo.loginAdministrative(null);
Session userSession = adminSession.impersonate (new SimpleCredentials("<userId>",new char[0]));
log.debug(“Session is: {}”, userSession.getUserID());
Q: What if there are two groups of marketing users that want to author the same site/page at the same time but have a different release schedule? How would you solve this problem?
Ans: We can create two launches for each release and various teams can author content and release at different times. Launches is a new feature in AEM(5.6) and documentation can be found here.
Performance problems in CQ can be due to many things in combination. Here are few performance tuning tips which improve your CQ performance.
/crx/explorer/index.jsp - CRX explorer
/crx/de/index.jsp – CRXDE Lite url
/libs/cq/search/content/querydebug.html – Query debug tool
/libs/granite/security/content/admin.html – New user manager standalone ui [5.6 only?]
/libs/cq/contentsync/content/console.html – Content sync console
/system/console/bundles – Felix web admin console
/system/console/jmx/com.adobe.granite.workflow%3Atype%3DMaintenance - Felix web admin console JMX / Workflow maintenance tasks
/system/console/jmx/com.adobe.granite%3Atype%3DRepository - Felix web admin console JMX / Repository maintenance tasks
/etc/reports/diskusage.html?path=/content/dam – To know the size of the repository
wcmmode=DISABLED - This handy publisher parameter turns off CQ authoring features so you can preview a page cleanly
/system/console/depfinder – This new 5.6 tool will help you figure out what package exports a class and also prints a Maven Dependency for the class.
If you have more handy URL’s and or parameters that you think others should know about please comment on this blog entry and I will add them to the list.
The following is the sequence recommended by Adobe. A sample RHEL 6.3 shell script that invokes these operations using curl is available for download here.
ONCE PER DAY
——————————
BACKUP
1) Backup
OPTMIZATION
The elapsed times reported below are for a virgin CQ “author” instance with about 70,000 nodes and about 350,000 properties hosted on an SSD.
2) Tar Index Merge
3) Tar Optimization (~ 2 minutes)
This defragments the repository Tar files. For massive DAM ingestion operations, here is a model that can predict how long this would take.
4) Tar Index Merge (again)
The automatically scheduled Tar optimization does in fact do an index merge, Tar optimize, and a second index merge.
FOR DEV Environment:
5) Consistency Check (~ 3 seconds)
6) Traversal Check (~ 4 seconds)
In addition, the following CQ Knowledge Base article discusses ways to prevent repository inconsistencies from occurring. Here are links to the sample (v5.6)repository.xml, workspace.xml and start.bat (Windows). Please note that these settings do slow down CQ startup times, the bigger your repository, the longer the startup.
ONCE PER WEEK
———————————
1) Datastore Garbage Collection (~ 4 minutes)
This removes orphaned files in the datastore that are no longer referenced from within the repository. The bigger the data store, the longer this operation will take. See this for a model to predict this.
If your repository is large, you can choose to start the following operations at a level lower than at the top (/ which represents the root of the hierarchical Java Content Repository). E.g. /content/dam/MySite1Assets for Start Path.
Source: http://cq-ops.tumblr.com/post/29627149909/recommended-sequence-of-cq-maintenance-operations
CQ comes with a page that can be used to query its repository at http://server:port/crx/explorer/ui/search.jsp
Copy-paste them into the “Query” field and hit the ‘Search Now’ button. Scroll to the bottom of the page to see total reported numbers.
Make sure you are logged in to CQ as “admin”.
Total number of nodes
// * order by @jcr:score
Total number of CQ pages
// element(*, cq:Page) order by @jcr:score
Number of audit events
// element(*, cq:AuditEvent) order by @jcr:score
Number of digital assets in DAM
// element(*, dam:Asset) order by @jcr:score
Number of images
// metadata[jcr:like(@dam:MIMEtype, ‘image/%’)] order by @jcr:score
Number of tags
// element(*, cq:Tag) order by @jcr:score
Number of workflow instances
// element(*, cq:Workflow) order by @jcr:score
Number of websites that are “Live Copies” of other websites
// * [@cq:master and not(@jcr:frozenUuid)] order by @jcr:score
Source: http://cq-ops.tumblr.com/post/29906959491/search-queries-to-determine-the-size-of-cqs-repository
In CQ DAM, files larger than a configurable size (4 KB by default) are kept in a separate “DataStore”. This DataStore can be located on a separate disk or disk array for performance reasons.
When digital assets are deleted from CQ DAM, they are only “marked” for deletion. The real cleanup of the DataStore happens during a process called “DataStore Garbage Collection” (DS-GC). This can be triggered from the Apache Felix OSGi Console (JMX tab) - click on the “Repository” MBean.
How long the DataStore Garbage Collection takes depends on the size of your CQ DAM repository. A property called ’DataStoreGarbageCollectionDelay’ controls how long (in milliseconds) this process pauses after processing 10 JCR nodes. By default, this is 10 milliseconds.
For example, if your JCR has 25 million nodes (the result of about 250,000 assets), the scan will take (25 million nodes/10 nodes) x 10 milliseconds = about 7 hours. The scan happens twice during a single DS-GC run - so the delay would be about 14 hours.
Testing by Adobe’s Server Performance Lab shows that the duration of this garbage collection can be significantly reduced by changing the value for ‘DataStoreGarbageCollectionDelay’ from the default “10” milliseconds to a lower number. On one lab machine, setting this to 0 caused the duration of DS-GC to go from about 2 hours down to 7 minutes. Of course, on a busy PRODUCTION system, 0 is a bad idea.
To change the value, just click on the 10.
Source: http://cq-ops.tumblr.com/post/35642664963/speeding-up-cq-dam-datastore-garbage-collection
