I just started at my new job and found myself right in the middle of a big project using Adobe AEM CQ, which I've never used before. Currently there are developers creating and tweaking components while content authors are busy authoring about 65 pages of content using those components.
Obviously, every time a component changes someone needs to update all the authored content with the new component changes. This is a huge time-waster as it seems like the only way to do this is through a custom made script that looks for nodes in the xml files and tries to convert them to the new component specs. Sometimes this is not even possible and authors need to re-author tons of stuff and lose lots of time.
Can anyone with AEM experience please let me know if:
1) There is a more painless way to migrate authored content to new components?
2) There is a better way to have developers and authors work simultaneously?
I know that the ideal way is to develop components first, and then author on top of those but it seems unrealistic especially with a big client project where things change all the time.
Thanks
Firstly, it sounds like a business process problem. The components should be fully developed and fully tested before content is being added by the authors. If the edits to components are so different that you're having this problem, i would recommend having functional and technical requirements written before the build starts.
With that said, the Groovy console for AEM is an excellent tool for updating nodes and content within an AEM site. Take a look at it here: https://github.com/Citytechinc/cq-groovy-console
I would not agree that content production should happen after all the components where developed. It's beneficial, especially when the content production will take a lot of time, to start it while the development is happening.
On the other hand I completely agree with the other part of the answer. Groovy Console is a way to go, when dealing with content migration (both before Go Live and after, during BAU process). Ideal situation is where all the current content can be mapped to data in new version of component. Then you should be able to migrate all the content with scripts. If that's not the case then you can't run away from authors putting the content manually.
Definitely components should be fully developed before their usage.
But if you want to change something specific in a component which will remain same for the entire website just like logo component or header component you can look into the Design Dialog.
So advantage of it is:
If you have already done authoring for n pages, when you change the component using Design Dialog it will be automatically reflected in all the pages wherever the component is being used.
AEM is a CMS where content is your data is put it in simpler terms. If your development process is such that data is inconsistent with the UI after every release then your delivery process might be at fault. You can use the following ways to make things better:
Make components backward compatible with the data
Make components version-able, i.e. new versions of components work with new models of data and it's left to the user to use new versions.
Provision for data or component migration in your project plan.
In practice, most AEM implementation make components backward compatible and provide an upgrade path to new versions. This is not a technical problem, it's more of a project governance issue.
This post is resurfacing so don't want people to get wrong idea from the current state of answers (and some answers that should be comments IMHO) but the approach in general to deal with components and releases is not a technical problem of the platform.
Related
Situation:
I work for a multinational/global organization in the HR dept as Engineering Manager.
HR needs a lot of content related to Immigration, Benefits, Leaves, Disability, Transfers, New Hire Onboarding, Covid Policies, Expense Policies.
These are rendered thru documents/Knowledge bases. As you can imagine for a global corporation that is present in multiple countries this problem can get very complex soon.
Almost all of the content is in terms of text/documents that are not really structured.
Today we are using AEM as the Content Management Platform. AEM was being used in a headful manner but AEM imposed a lot of restrictions when we had to develop Applications on top of AEM
So we are going to use AEM in a headless manner and bring in all the content in content fragments so that those content fragments can be rendered on different portals (some use cases need more than 15 portals)
Questions:
Does it make sense imposing structure on these documents?
Does continuing to use AEM make sense here?
We want to enable reuse of pages : One page is rendered on multiple platforms.
We want to enable reuse of text blocks: One block of text could be used on multiple platforms.
How do we derive information such as breadcrumbs?
How do we build an information tree: e.g. article A , B , C should be shown under US-> Leaves-> Maternal leaves while D,E,F should show under Global -> Leaves -> Bearevent Leaves. That information is not going to be present in content fragments.
How do we build a site map?
How do authors discover information? If I write a content fragment - how do I manage its taxonomy?
Just in case - AEM also delivers any content as json or xml. Or, if your sling models are set up for model.json, you even get a json representation with all the context you need.
So I am not really convinced that this statement is true:
AEM imposed a lot of restrictions when we had to develop Applications
on top of AEM
I have seen projects using experience fragments combined with content fragments in "real" AEM pages. That way you can reuse and combine content parts on several levels and even make use of the multi site manager feature.
Using tags or custom metadata fields (based on a central taxonomy) will help you add information you might need to display content parts without enclosing elements. All you need is a servlet that returns all the content or experience fragments with the right tags attached.
It's hard to tell you more here without doing the complete rwquirements engineering ;-)
in AEM,
do via writing different scripts that use different selectors
do via using reference components
perhaps render breadcrumbs using page path
use a tree structure of tags and tag the items accordingly
you may want to create a custom left side authoring pane picker
The other things are more complex (site maps!) but all can be done with AEM.
You can also use AEM to do some of those things and do other ones outside of it.
I tried my best to answer it :
Does it make sense imposing structure on these documents?
Structuring document will give you more control over content, even better to strategies it. It will help in several things such as planning, searching, filtering.
Does continuing to use AEM make sense here?
I don’t know your exact business entirely however if content have more static content unlike real time websites live update in data then it will help surly.
in addition, CMS market AEM mold good in compare with other CMS such as Sitecore. others CMS using databases whereas AEM content repository. it is debatable which is good
We want to enable reuse of pages : One page is rendered on multiple platforms.
if you are saying pages means it an HTML experience division of page. AEM has good feature of experience Fragment. Yes, there is challenges but still this will fit efficiently
We want to enable reuse of text blocks: One block of text could be used on multiple platforms.
Here also experience fragment can be a good fit, make as many variants as possible you want and reuse it
How do we derive information such as breadcrumbs?
I do not know exact wanting here but I would say implement multiple breadcrumbs for small segments or can implement custom breadcrumbs to target content small segments accordingly. Here if you content is well designed then breadcrumbs will not be real challenge
How do we build an information tree: e.g. article A , B , C should be shown under US-> Leaves-> Maternal leaves while D,E,F should show under Global -> Leaves -> Bearevent Leaves. That information is not going to be present in content fragments.
You can also manage it through Template and restrict the template in a way that page will be created under certain tree. In other way, make taxonomy in such a way it creates structure you have given for example parent page (HR work, Engineering) for each and every business unit its ok to have redundant content, use MSM feature also tag them meaningful way.
How do we build a site map?
As in breadcrumbs, you can also build sitemaps for small segments such as one for HR/US and Engineering/US render them individual or together it does not matter. It will be still well design sitemap
How do authors discover information? If I write a content fragment - how do I manage its taxonomy?
Either to make folder structure in certain way or make variants and use tagging framework
To conclude - No product will be 100% fit for any requirement, it’s just you have to use the product in such a way it will be more and more suitable for your requirement.
Good luck!
I am an Epicor and Crystal Reports Newbie. I have started working with these programs a month ago, when I was hired. I am still trying to figure out how you know whether you are trying to customize a BAQ, Dashboard, etc. How to know where/when to make a new BOM report and such. If anyone out there has some tips, I would greatly appreciate it. I feel slightly intimidated by the program but am also determined to learn my way through it.
Thanks!
Toohey! Welcome to the world of Epicor!
Although I'm sure in the past couple of months you have learned the ropes, here are some extra tips to keep you moving forward:
That is not part of the system functionality
In order to keep costs under control, err on the side of not making system customizations to meet all user requests. You will quickly see that adding a quick field as a customization to a form isn't just the 5 minute change it seems like. You will soon be creating several custom reports and dashboards to report off of this field, and the cost of the change soon outweighs the benefit in many situations. As you become more familiar with this, try to balance ROI against the high cost of Epicor system customizations. It is best to lead with "that is not part of the system functionality", and when they push the issue, treat even small changes as controlled projects.
BAQ and Report Changes
Inevitably, you will need to customize the system's BAQs and Reports to meet your business needs because the standard system isn't designed exactly for your business.
Epicor has standard BAQs that start with 'z' and many reports. You should avoid editing the stock BAQs and reports, because they will be overwritten with each patch of Epicor. Instead, copy the standard distribution BAQs and rename the copies using your company initials as a prefix. Similarly, you want to create a custom reports folder separate (or within) the standard reports folder where you place all of your modified reports. You can then link the menu to the BAQ Report or Report Data Definition, and link the report style to the location of your new custom report on the server.
Customizations
Maintenance of customizations has a high long-term cost if you do not have in-house developers. A critical piece of advice here is to make sure all of the code, be it in C# or VB, is thoroughly commented. Even if you're generating code with a wizard, do yourself a favor and put a standard header into the script of every customization that includes the first date of the customization, when it was modified, and detail everything that was changed (especially if the change was a property change or a field addition that does not clearly appear in the script). Customizations have been known to fail for unexplained reasons, or create bad script that is not editable through the standard Epicor interface, and there may come a time when you have to rebuild the customization from scratch using only this change log and things you can clearly see in the form. You should save your customizations with some obvious standard naming convention (something like ORDER_ENTRY_CSR_YYMMDD), and make sure you update all menus to reflect the newest customization for the purpose you're using it. We also export our customizations for archival, just in case something should happen. Another note here is if you do not increment the customization name on a change and then update the menu items, users will still be use locally cached versions of the page until they clear their client cache. So, I always recommend incrementing. Another note on customizations and every custom exportable object in Epicor is to do yourself a favor and export them to either a source control system or a file repository so that after you deploy a faulty customization, rolling back to the previous version is quick and painless.
BPM Directives
As you're probably aware by now, BPM directives are powerful tools which can be used to update tables and prevent users from making terrible business decisions. A note on these is similar to customizations - comment comment comment!
Consultant Use
If you are using external consultants to create BPMs or Customizations, mandate distribution of commented source code that can be understood internally by one of your team members.
I hope this helps!
Source: 4 yrs experience as an Epicor ERP programmer
I would like to add that you should develop any Customization, BPM or Baq/Dashboard in the test system because any error on a solution can stop users from perform their job. Also, you can use a powerful tool called tracing options that helps you to recognize where to place the BPM directives. Further more there is a huge Epicor forum where you can post questions and a comunity of consultants , developers and users will answer your questions, and advise you about best Epicor practices, and it is completely free. You need to register on it; this is the link www.e10help.com.
I am working on a website of 3,000+ pages that is updated on a daily basis. It's already built on an open source CMS. However, we cannot simply continue to apply hot fixes on a regular basis. We need to replace the entire system and I anticipate the need to replace the entire system on a 1-2 year basis. We don't have the staff to work on a replacement system while the other is being worked on, as it results in duplicate effort. We also cannot have a "code freeze" while we work on the new site.
So, this amounts to changing the tire while driving. Or fixing the wings while flying. Or all sorts of analogies.
This brings me to a concept called "continuous migration." I read this article here: https://www.acquia.com/blog/dont-wait-migrate-drupal-continuous-migration
The writer's suggestion is to use a CDN like Fastly. The idea is that a CDN allows you to switch between a legacy system and a new system on a URL basis. This idea, in theory, sounds like a great idea that would work. This article claims that you can do this with Varnish but Fastly makes the job easier. I don't work much with Varnish, so I can't really verify its claims.
I also don't know if this is a good idea or if there are better alternatives. I looked at Fastly's pricing scheme, and I simply cannot translate what it means to a specific price point. I don't understand these cryptic cloud-service pricing plans, they don't make sense to me. I don't know what kind of bandwidth the website uses. Another agency manages the website's servers.
Can someone help me understand whether or not using an online CDN would be better over using something like Varnish? Is there free or cheaper solutions? Can someone tell me what this amounts to, approximately, on a monthly or annual basis? Any other, better ways to roll out a new website on a phased basis for a large website?
Thanks!
I think I do not have the exact answers to your question but may be my answer helps a little bit.
I don't think that the CDN gives you an advantage. It is that you have more than one system.
Changes to the code
In professional environments I'm used to have three different CMS installations. The fist is the development system, usually on my PC. That system is used to develop the extensions, fix bugs and so on supported by unit-tests. The code is committed to a revision control system (like SVN, CVS or Git). A continuous integration system checks the commits to the RCS. When feature is implemented (or some bugs are fixed) a named tag will be created. Then this tagged version is installed on a test-system where developers, customers and users can test the implementation. After a successful test exactly this tagged version will be installed on the production system.
A first sight this looks time consuming. But it isn't because most of the steps can be automated. And the biggest advantage is that the customer can test the change on a test system. And it is very unlikely that an error occurs only on your production system. (A precondition is that your systems are build on a similar/equal environment. )
Changes to the content
If your code changes the way your content is processed it is an advantage when your
CMS has strong workflow support. Than you can easily add a step to your workflow
which desides if the content is old and has to be migrated for the current document.
This way you have a continuous migration of the content.
HTH
Varnish is a cache rather than a CDN. It intercepts page requests and delivers a cached version if one exists.
A CDN will serve up contents (images, JS, other resources etc) from an off-server location, typically in the cloud.
The cloud-based solutions pricing is often very cryptic as it's quite complicated technology.
I would be careful with continuous migration. I've done both methods in the past (continuous and full migrations) and I have to say, continuous is a pain. It means double the admin time for everything, and assumes your requirements are the same at all points in time.
Unfortunately, I would say you're better with a proper rebuilt on a 1-2 year basis than a continuous migration, but obviously you know best about that.
I would suggest you maybe also consider a hybrid approach? Build yourself an export tool to keep all of your content in a transferrable state like CSV/XML/JSON so you can just import into a new system when ready. This means you can incorporate new build requests when you need them in a new system (what's the point in a new system if it does exactly the same as the old one) and you get to keep all your content. Plus you don't need to build and maintain two CMS' all the time.
I am working with a client who has an ERP system in place, called M1, that they are looking to make custom changes to.
I have spent a little bit of time investigating the ERP system in terms of making customizations. Here is a list of what I have found with regards to custom changes:
Custom changes cannot be exported/imported. There is an option in the M1 Design Studio, however, they always appear to be disabled... I tried everything and I couldn't find a mention of it in the help documentation.
You can export a customizations change log (CSV, XML, Excel, HTML) that provides type, name, location and description. In essence, it is a read-only document that provides a list of changes you made. You cannot modify the contents of this log.
Custom form changes made, go into effect for all data sources (Test, Stage, LIVE). In other words, there does not appear an ability to limit the scope of a form change.
Custom field changes must be made in each data source (Test, Stage, LIVE). What's odd here is that if add a field in Test, adjust a grid to display it, subsequently change to LIVE, it detects that the field doesn't exist and negates the grid changes.
I'm unable to find documentation indicating that this application supports version control.
sigh
....
So...
How do I manage changes from an SDLC: ALM methodology and tools standpoint?
I could start by bringing in a change request system to manage pending and completed customizations. But then what? How should changes me managed and released? Put backups of application under source control and deploy when needed?
There might not be a good answer to this question since I'm unable to take advantage of version control and create a separation of environments, but I figured I'd ask in case anybody has had similar experience or worked with M1.
I take it from the lack of answers in two months that your question is unanswerable. SDLC is something you could write a textbook on, or read a textbook on, and not know enough about your environment, other than that probably in order to get hired at your shop, "SDLC" would be a bullet point on the hiring qualifications.
I have no experience with M1, but I am assuming that you're going to have to ask your peers at work for their ideas, because it sounds like you're asking a vertically closed (your shop, your tools, your practices) question that has no exact technical answer.
As for best practices; I suggest you investigate best practices outside your M1 ERP silo and apply them as makes sense to you.
The company I work for also uses M1 erp. We have similar issues regarding version control of the customisations. From what I can tell, all customisations are stored in the M1DD database. You could backup a copy of this database before any major development work as a basic revision control system.
I am familiar with the issue of all changes becoming immediately active in all datasets. This is particularly annoying when you are making changes to a commonly used modules as you don't know how live data will be affected during the development process. One technique I have found useful is to surround untested code with an if statement so it is only executed when I am logged in.
If App.UserID = "MYUSERNAME" Then
'new code here
End If
I would be interested in hearing how you solved this problem.
We have a web application which contains a bunch of content that the system operator can change (e.g. news and events). Occasionally we publish new versions of the software. The software is being tagged and stored in subversion. However, I'm a bit torn on how to best version control the content that may be changed independently. What are some mechanisms that people use to make sure that content is stored and versioned in a way that the site can be recreated or at the very least version controlled?
When you identify two set of files which have their own life cycle (software files on one side, "news and events" on the other, you know that:
you can not versionned them together at the same time
you should not put the same label
You need to save the "news and event" files separatly (either in the VCS or in a DB like Ian Jacobs suggests, or in a CMS - Content Management system), and find a way to link the tow together (an id, a timestamp, a meta-label, ...)
Do not forget you are not only talking about two different set of files in term of life cycle, but also about different set of files in term of their very natures:
Consider the terminology introduced in this SO question "Is asset management a superset of source control" by S.Lott
software files: Infrastructure information, that is "representing the processing of the enterprise information asset". Your code is part of that asset and is managed by a VCS (Version Control System), as part of the Configuration management discipline.
"news and events": Enterprise Information, that is data (not processing); this is often split between Content Managers and Relational Databases.
So not everything should end up in Subversion.
Keep everything in the DB, and give every transaction to the DB a timestamp. that way you can keep standard DB backups and load the site content at whatever date you want if the worst happens.
I suppose part of the answer depends on what CMS you're using, and how your web app is designed, but in general, I'd regard data such as news items or events as "content". In other words, it's not part of your application - it's the data which your application processes.
Of course, there will be versioning issues between your CMS code and your application code. You could manage this by defining the interface between the two. Personally, I'd publish the data to the web app as XML, which gives you the possibility of using XML schema to define exactly what the CMS is required to produce, and what the web app should expect to process.
This ought to mean that most changes in the web app can be made without a corresponding alteration in the rendering of the data. When functionality changes require this, you can create a new version of the schema and continue to make progress. In this scenario, I'd check the schema in with the web app code, but YMMV.
It isn't easy, and it gets more complicated again if you need additional data fields in your CMS. Expect to plan for a fairly complex release process (also depending on how complex your Dev-Test-Acceptance-Production scenario is.)
If you aren't using a CMS, then you should consider it. (Of course, if the operation is very small, it may still fall into the category where doing it by hand is acceptable.) Simply putting raw data into a versioning system doesn't solve the problem - you need to be able to control the format in which your data is published to the web app. Almost certainly this format should be something intended for consumption by software, and therefore not usually suitable for hand-editing by the kind of people who write news items or events.