I have some basic questions related to publishing.
If I have a component A which has a multimedia link to Component B.
When I publish component A using a dynamic CT, the component B will also be published.
Will component B's custom meta-data also get published? (I couldn't locate the custom meta-data in transport package for component B)
If I unpublish component A, It will also unpublish component B? But what if component B is linked and published with several other components?
If I insert a component on a page using a dynamic CT, after publishing, will the component Presentation get added to database, or as a static part on page or at both locations? (We use file system for pages and broker DB for dynamic CPs)
I know these are basic questions, but these will solve several doubts. thanks.
If I have a component A which has a multimedia link to Component B. When I publish component A using a dynamic CT, the component B will also be published.
This is not true. To publish multimedia links you have to use <img src="tcmid" ..... /> for your multimedia link to be published and your CT needs to include Default Finish Actions which contains Publish Binaries in package.
Typically When you publish Component A, it will only publish multimedia file (img,jpg,pdf etc) when you have above line of code in your DWT and you have the TBBs mentioned above.
Q # 1 : In this case metadata will not be published since you are just publishing the multimedia file via code
Q # 2 : Multimedia File will not unpublished when you unpublish Component A if it is being used or referenced. Tridion Deployer checks if there are any references to the multimedia file and deletes the file only if it does not have any references.
Q # 3 : Publishing to databasse or filesystem is not just based on simply Dynamic CT. It is based on your storage configuration on your deployer side. It based on what you configure in the storage either to db DB or FS.
If you want to publish Multimedia Components dynamically you need a Dynamic CT associated with that Multimedia Schema (OR) You could write a C# TBB as part of your Dynamic CT of the same for Component A and publish dynamically via code.
Here is Tridion documentation you can also check, may not be straight forward answers to your questions, but will provide some additional information.
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_56BCD7B2A1994C76B940751B2458D8E0
Related
We have a requirement that on a page publish, we need to:
Find a component presentation that has a component based upon a particular schema.
Extract certain field vales from that component and store them in a custom database table that's available to our .NET application (on the Content Delivery side).
I think this is a good candidate for either a Deployer extension or a Storage extension - but I'm a little unclear which and why having never written either?
I've ruled out the Event System as this kind of code would be located on the CM, which seems like the wrong "side" to me - my focus is on extending what happens on the CD-side after a page is published.
Read a few articles on Tridion World (this, this, this and this) and I think a storage extension would be the better choice?
Mihai's article seems to be very close to what we need, where he uses a new item type mapping:
<ItemTypes defaultStorageId="brokerdb" cached="true">
<Item typeMapping="PublishAction" cached="false" storageId="searchdb" /></ItemTypes>
But how does Tridion "know" to use this new item type when content is published, (its not one of the defined TYPE_NAMEs, which is kind of the point)?
I should clarify I'm a .NET/C# dev not a Java dev so this is probably really obvious to Java people - apologies if it is!
Cheers
Tridion will not know by default how to deploy your new entity. My advise is to create a Deployer Module (your links should give you enough information about how you can do that) that executes in post-processing phase (of the deployment process), that processes all components from the deployment/transport package, extracts the needed information and uses a custom Storage Extension to store the needed information.
Be careful: you need to set-up in config your new type but you also need to use it yourself from that Deployer Module.
Hope this helps.
We are iterating the components in a folder in Tridion 2011 and creating our custom XML to be used on CDS on the basis of the publishing status of component. I am giving below example to make you understand the problem.
Supppose we have 10 components in a folder which are all published and we publish our XML then the XML gets generated for 10 items.
Now we make change in one of the component and don't publish it.
After modification of component, we publish the XML again. then the XML get updated for the modified component also. So it creates the difference between the published version of that component and the that is in our XML.
So I want to publish the custom XML in such a way that it should only contain that data which is in sync with published version of component.
So you want to:
determine the XML of the Component that was last published
determine the changes between that XML and the current XML of the Component
only publish the changes
Tridion doesn't keep track of the version that was published (on the Content Manager at least). So the closest you can do is find out when the Component was last published and retrieve the XML of that time. This question is a great starting point for more information on that approach. Based on that XML you can then do steps 2 and 3 above.
Alternatively you can keep a snapshot of the XML that you published "somewhere" (for example in Application Data) when you're rendering the Component. Then when the Component gets published next time, you can retrieve that XML and do steps 2 and 3 above.
Note that with any of those solutions you should really wonder if you should be implementing it to begin with. You are overriding some of Tridion's default rendering behavior and circumventing part of its architecture (a clear, explicit disconnect between Content Management and Content Delivery, with the former knowing "nothing" about the latter) and anything you do will come back to haunt you in time. In this use-case you have to wonder what will happen when the CDS and TCM get out of sync. Simply republishing the content suddenly won't be good enough anymore, since your code will be in there deciding that "nothing changed since last publish, so we'll publish nothing".
Please forgive me if I jump to conclusions, but I strongly feel this question has arisen from a lack of understanding of Tridion. Publishing in Tridion does more than just raise a flag to indicate the item is 'published', in other words ready to be shown to the outside world. I know this is how some (many) content management systems operate (which may explain why you are asking this question).
In Tridion, however, publishing means that the item is actually - physically - transferred from the content management environment to the content delivery environment. This environment always contains versions of your content that represent the state when the item was last published - simply because it was the very act of publishing that created them.
In my opinion, what you are really asking is how to rebuild this publishing functionality. This is never a good idea. Instead, you should take Bart's comment seriously and look at one of the content delivery APIs that Tridion has on offer (the broker API or the OData web service). Optionally you might want to look into DD4T, which is built on top of the broker and exposes the full Tridion data model.
Then your solution is to
Write an event handler on the Publish Transaction Save event
Which saves the publish info (version data) to Application Data of the published Component
I'm mentioning the Publish Transaction Save event because from there you can ensure that the publish info is only saved when the transaction is successfull.
Also be aware that this publish info can go out of sync when the event handler fails to execute, and you might loose all of the application data when moving to another environment.
So when this information is absolutely crucial I would save it to a separate database, and not to Application Data.
We have large number of publications and currently we manually apply the CMS permissions across multiple environments (UAT and PROD mainly). This is tedious and often times error prone.
We are trying to export and import the CMS permissions across multiple environments, so this could be done once manually and ported to other environments using some sort of tool.
Environment: Tridion 2011 SP1 + IIS 7.5 + SQL Server 2008 r2
In Old PowerTools (VBScript) there used to be some tool to manage Access management which could be handy, still error prone. We are not interested to use the OLD powertools for obvious reasons and it is recurring operation function so DB option is ruled out as well.
We are considering to build a tool using Core Service, that could export and Import the permissions. We have the same Groups, Publications and Folder structure across these environments.
Has anyone tried this before? What are the experiences or practices that other fellow Tridioneers used in large implementations.?
Any view points are greatly appreciated.
I once wrote a tool that allowed you to describe your desired permissions settings as JSON, and apply them via the API. To be honest, if you were to write a DTAP-security tool, I'd follow a similar approach. Start by being able to express your desired settings in an open, text-based format, then write a tool that imports them. Once you have this, you can easily build a tool that exports them.
I created a security migration tool in Tridion 5.2 but the solution approach will still apply to current versions of Tridion
Summary
The solution used a set of simple vbscript export page templates to extract the security information as xml and store it in a set of components.
I then used Tridion Content Porter to move these security components, page templates and tbbs's to the target CMS's
Using set of simple import page templates to open the security xml components to apply the security setting to the target cms.
The tcmid's will be different in the target cms so the import functions must use webdav urls and build dictionaries of tcmid's for trustees etc
Details
Export Security Groups
iterate selected Groups
append group xml
save xml in component
Export Publication Rights
getlistpublications
iterate list of publications
get each publication xml
remove "//tcm:CategoriesXSD" node
appendChild publication xml
remove unwanted "//tcm:Trustee" nodes
save xml in component
Export Folder Permissions
recursively iterate folders
append Folder XML
remove trustee nodes that are inherited ("IsInheritanceRoot")
save xml in component
Export Structure Group Permissions
recursively iterate Structure groups
append structure group XML
remove metadata node "//tcm:Metadata"
filter out unwanted Trustees
save xml in component
Import Security Groups
load xml from security component
iterate group nodes
create groups if they don't already exist
Import Publication rights
load xml from security component
update xml tcmid's
iterate publications
load publication xml
build xml updategram
update publication xml
Import Folder Permissions
load xml from security component
update xml tcmid's
for each folder node
build updategram xml
open folder
update folder xml
Import Structure Group Permissions
load xml from security component
update xml tcmid's
for each structure group node
build updategram xml
open structure group
update structure group
I've struggled with a better solution for the following setup. I'm not actively working on this, but know some that might appreciate other ways of handling this.
Setup:
Tridion-managed page has a single "linked list" component Linked list
Single component has component links to other components in Tridion
Linked-to components often link to multimedia component (mm)
An XSLT component template (XSLT CT) renders XML with above content and with links to PDF
XSL document() function used to grab embedded (linked-to) content, all content converted to XML nodes and attributes
TCMScriptAssistant namespace with publishBinary() publishes related PDF and other media
Page template just outputs the result of the CT
Business requirements:
improved publishing (last I worked on this, some of these files created a 2GB publishing transaction because of the PDFs)
published XML content file must reference the associated PDFs; hyperlinks work but identifiers might not help because of...
no Tridion content delivery APIs, mainly for independence from the storage database but also to avoid Tridion-specific code on the presentation server (loosely coupled setup and less training for developers)
The biggest issue is the huge transport package during publishing. The second problem is publishing any of the linked-to PDFs will cause the page to republish.
How could this setup be improved or re-engineered, preferably without too many changes to the existing templates, though modular templating could be considered.
Dynamic component presentations could possibly work, but would need to be published to the file system and not use dynamic linking or broker objects (e.g. no criteria filters, binary metadata, etc).
There are indeed 2 questions. I will handle them in reverse order.
To prevent the page from being republished when you publish a binary, you can use the event system in older versions of Tridion (pre-2011) to turn off link resolving, or with newer versions you can use a custom resolver to prevent this. There is an article by Nuno which explains this(http://nunolinhares.blogspot.com/2011/10/tridion-publisher-and-custom-resolvers.html)
Your second one is a bit tougher, in no small part because of your criteria for not using the SDL Tridion CD APIs. I would have suggested publishing the binaries separately (this would keep the file size down of your transaction package), and using Binary Linking to resolve the paths at request time.
Given this is not an option, I think the only was I would approach it would be to still use dynamic component presentations, and then use predictable unique file names for the PDfs (i.e. use something like 317-12345.pdf based on the URI), and use one directory for all the binaries. That way you could enter the paths to the binary using your XSLT template, as you know where the binaries will be located later. You could then use a custom resolver to publish the binaries when you publish the main list component or page.
Hope that helps
Chris
I know the drill - Choose Items - point to the dll - voilà!
But there are some attributes on the pipeline component. Does these affect the visibility? And how to change these?
<ComponentCategory(CategoryTypes.CATID_PipelineComponent), _
ComponentCategory(CategoryTypes.CATID_Any), _
ComponentCategory(CategoryTypes.CATID_Validate), _
System.Runtime.InteropServices.Guid("E7C186DF-D5DD-46a0-90A4-A2A6804763B0")>
ublic Class clsComponent
Implements IBaseComponent, Microsoft.BizTalk.Component.Interop.IComponent, IPersistPropertyBag, IComponentUI
I know this is an old post, but according to Microsoft, here is what you need to do:
http://msdn.microsoft.com/en-us/library/aa577482(v=bts.20).aspx
All the .NET pipeline component assemblies (native and custom) must be located in the \Pipeline Components folder to be executed by the server. If the pipeline with a custom component will be deployed across several servers, the component's binaries must be present in the specified folder on every server.
You do not need to add a custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).
Custom COM components in the pipeline will also appear in the Toolbox, provided they are registered on the computer as a COM component. Custom .NET pipeline components must be placed into the \Pipeline Components folder.
After the binary files are in the correct location, you need to add the component to the Toolbox. For instructions on adding the pipeline component to the Toolbox, see How to Use the Toolbox.
If I understand your question correctly, you've written a custom PL component, are trying to add it to your custom PL, have gone to choose from the Choose Items tool box and its not appearing?
These might be obvious but double check that you've performed the following steps;
a) GAC'd the PL Componet Assembly.
b) Copied the PL Component DLL to the BizTalk Install Location\Pipeline Components folder.
c) Closed and Re-started your PL Solution.
You should now be able to see your Custom PL Component in the Choose Items Box.
HTH