nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Teamsite, DataDeploy, and ATG Dynamo Integration

plantronics

I am a Teamsite administrator and template engineer also with some webapp background and recently Ive been given the task of integrating Teamsite more closely with our application server which is ATG Dynamo. Essentially Im looking for input and practical examples (not marketing) on the integration points between Teamsite and Dynamo. Specifically in using templating to automate data entry for Dynamo repository content.

Our big problem now in managing the content of the website is that we have two disparate data sources. One being in Teamsite (DCRs and flat files), and one being repository data that is accessed and authored via the Dynamo DCC (or ACC as it is now called). Not having a single content authoring environment has proven to be a missed step in our original implementation, and something we want to re-examine as we upgrade both products.

To date, Ive found it challenging to find any really useful info on this topic other than some broad overviews, white papers and case studies, so I turn to you at Devnet to hopefully provide some useful technical resources which would help me visualize and propose such a solution. of course we are currently looking at DataDeploy as the main puzzle piece that would tie the repository to Teamsite, yet details on what such a solution would look like are still unclear. You input is much appreciated!

Find more posts tagged with

Comments

gzevin

look, have you tried getting so called 'Turbo' packages from Interwoven? I am sure ATG integration has been done before.

as to the exact advice on your requirement, I am afraid you did not supply full details and also business requirements for the integration.

but, as far as I remember, integration with Dynamo was more a creation of custom-XML DCRs, that could be directly read by ATG, thus having TeamSite as a main entry point.

But, frankly, I think you need a few days of an experienced consultant to run some discovery sessions and then present you with a suitable architecture

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

plantronics

Thanks for the input Greg. Do you know if the DCRs that Teamsite creates out of the box are suitable for loading into ATG's repository framework? Or must the files follow an ATG specific DTD that is not native in Teamsite? I know the DataDeploy product would allow us to map DCRs directly to database tables, but Im unsure if custom configurations must be employed for ATG repository integration.

Mike

gzevin

OOTB DCRs definitely are not compatible with ATG. Yes, one can deploy the data from DCRs directly to a database. I myself would prefer producing custom DCRs, especially it's much easier now in TeamSite 6 and above. One could even enter data in one teamSite DCR and get a presentation template to generate a number of ATG XML files...

but again, as you can see, everything depends on your business requirements.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

plantronics

Your mention of custom DCRs in TS6 is interesting. Because it would seem redundant if we had to create a Teamsite DCR and also a specially formattted XML file for each DCR with basically the same information just to play nice with ATG. What you are saying it sounds like we can customize the output of XML within the Teamsite DCR to make it ATG friendly? If so this would be our preferred approach since it would mean less overhead.

Thanks,
Mike

gzevin

What you are saying it sounds like we can customize the output of XML within the Teamsite DCR to make it ATG friendly?

yes, one could do this before 6 (although it was a bit dodgy and clumsy). in 6 one could much easier control the appearance of target DCRs from DCTs.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

We use Teamsite 6, ATG Dynamo 6 and Websphere 5 at our company. When a user submits a DCR the tpl file will format it correctly for ATG. We have to do some interating inside the tpl file in order to get the correct format. But it's really not alot of work. We deploy the xml files to folders on the ATG server on an hourly basis. ATG then refreshes it's cache a half hour later. I also created a few perl modules that I slipped into the tpl files that can write everthing to a database (this was tricky and required some work) so that we can use ATG to use a SQL repository instead of an XML one. I like this method better because you can send a command to the ATG server to instantly refresh the SQL repository cache when a new piece of content is submitted. Instant publishing without having to use OpenDeploy or DataDeploy.

Everything you are asking can be done, I know, because I have done it.

plantronics

"When a user submits a DCR the tpl file will format it correctly for ATG."

Did you mean to say when the user <b>generates</b> the DCR it is formatted by the TPL for ATG? Or do you have a workflow built which merges the DCR with a TPL at submit-time?

I am interested in how templating users would preview their changes using your model. I will try to answer my own question and assume you have two TPLs, one for previewing the content in within the framework of the webpage (used when the user hits "preview" button on the DCT), and then one to create the ATG compatible XML (possibly triggered by a submit action on the DCR). Would I be correct?

If so, what would happen if the user were to "generate" the DCR from the DCT interface directly, as opposed to via a submit action performed via the WebDesk interface? Would they just see the ATG formatted XML document instead of an actual webpage?

Thanks,

Mike

gzevin

Mike,

I can see you are confused

if yoy remember, I mentioned generating ATG XML using tpl's as well, right? You might have 2 tpls - one that generates XML, another - for preview only. Or, you could have one tpl that would display HTML and generate XML at the same time.

As to WHEN and HOW you wan this to happen - depends totally on your reuirements and business processes. I would STRONGLY reccomed to do it in a workflow (this is what you mean when you talk about the submit button)

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

I only have on tpl. The user submits the dcr to a new workflow, then during the first task I run a perl command and generate an xml. I then use the perl copy command to copy the file out of the "y:\" drive on Teamsite into a folder on the "e:\" drive of the same server. On my atg box I map a drive to the folder on the Teamsite box and use the mapped drive as my repository. (Note, if you are running your Teamsite server on a Windows platform you will not be able to get Teamsite to copy the files to a mapped drive because Teamsite runs a the System account and that account cannot see the mapped drives properly, that is why I copy them out to a folder on the "e:\" drive and have my ATG system map to it) I then have the ATG appserver running a refresh every 5 minutes. Then the users can view their new content on the pre-production system. If you choose to use perl in the tpl to write out to a SQL database instead then you will be able to call a command to the ATG system to refresh your database during the xml generation, even though technically you aren't using the xml file on your ATG server.

Whooo, that was a lot.

plantronics

Thanks, this input is helping me. One thing I am still unclear on, is what happens say in the above case, when the user hits generate button from the DCT. Teamsite asks where you want to generate the file and you are prompted to enter a path and file name. Then it generates the output from the DCR against whatever TPL and forwards the user to the page. But take for example the above case where you arent generating an html page per say (rather it is generating XML, or just the DCR and nothing else). What role then does the generate button have? Are you disabling it in the templating UI, or just telling users not to hit the generate button, but just save, close and submit the DCR by itself (then kicking off the generating process behind the scenes in a workflow)?

Mike

gzevin

there could be 2 things. if the output directories are pre-set either in tpl or in a config file, generation from the button will not affect the target XML files.

but as a general precautionary measure (just in order not to confuse the users), I'd remove the button altogether

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

The generate button is removed from our dct's. The users cannot see it. I generate the xml files on the first task in the workflow. So, when the user submits and then starts the first task in the workflow it generates the xml and then copies the xml file and any attachments that I am referencing in the xml (all this is done is done custom in an external task) into a folder on the e:\ drive of the teamsite server. ATG then uses a mapped folder to that location for the xml files.

plantronics

So when a user say, creates a new replicant item in a Teamsite DCR, and saves it, you presumably use ATG's startSQLRepository to load that new content into a table somwhere and make it available as a repository item. But then how would one go about generating the unique keys in the gsa template XML for the repository ids?

Migrateduser

In the xml.tpl file I send all the data from the dcr into my sql tables. I then run a command similar to below. (No line breaks, spaces at end). This invalidates the cach and reloads the data from the sql tables. I does this during any generate commands. I pass it a param earlier in my code to determine which server to push the data to (prod or pre-prod) and which server to run the command against.

$command= "e:\\iw-home\\tools\\java1.3\\bin\\java.exe -cp e:\\iw-home\\tools\\java1.3\\bin\\classes.jar -Datg.adapter.gsa.invalidator.uri=rmi://servername:8860/atg/dynamo/service/GSAInvalidatorService atg.adapter.gsa.invalidator.GSAInvalidatorClient /repositories/modelsql/modelsqlRepository";

plantronics

Thanks!