This document will show how to integrate Content Server Workflow, using XMLWFX(XML workflow extensions) with StreamServe. A use case for this was CS users could generate XML dumps of documents or folder structures, and get a more user-friendly output that can be built dynamically and formatted almost however they like.
This assumes you have a general knowledge of Content Server Forms, XMLWFX & StreamServe:
Content Server Workflow XML Workflow Extensions with ELS & StreamServe Integration.
Content Server 10 (CS) with ELS
1) Below is a CS form that the users can use to select the object they want to XML export. XML export will generate an xml file put into which ever directory a user could choose and contain metadata like llnode, createdby, createdbyname, mimetype, name ect… The form chosen looks like this:
2) When presented with this form, you can now use the “Browse Content Server..” button and find a folder you would like to XML export. In this case, “Car” has been the folder to export. There is some custom HTML & CSS added to this view to make it somewhat more appealing however you can do a lot more.
3) Once you select Apply, it starts the workflow. The workflow looks like this and I will go into each step.
3a) Steps #1 are Modify steps and these allow me to move attributes FROM the form (shown in step 2) into the workflow (shown in step 3). The two attributes that are moving are “Export_Node” and a hidden attribute called “email”. This email attribute is auto populated with whichever CS user accesses the forms email address. This is so we can send them the report once it has been generated via Streamserve. A form replacement tag called “LL_UserMailAddress /” is used.
3b) Step #2 looks like this:
More detail about all these parameters can be found on the OpenText Knowledge center. I will only discuss the ones used here. The scope is set to 10 to only export 10 nodes deep from the parent. So in this case after selecting the Car folder, CS will export everything under Car, 10 folders deep (inclusive). Attribute = Target is indicating CS has requested this step to actually export whatever node is selected in the <Target> attribute. If you remember from step 3a), that is coming from the form which is actually “Car” node. Also [EXP]\test.xml set. [EXP] is a global export path that is set in the CS XMLWFX settings. This path is actually to a folder local to the STRS machine.
3c) This is the XSL transform step and where CS removes all the data you don’t actually want, and add some custom data.
Again, more documentation can be found on OpenText Knowledge Center regarding a lot of these parameters. Firstly you select what input file you want to transform (it is what you have exported in 3b), output file that you want to create once you have changed the data. Finally the stylesheet you want to apply. This stylesheet has to be created. I would consider this fairly basic, I have supplied some base syntax used here at the end of this document. The items near the bottom of the page are custom XSL parameters that you can add. You can see this done for:
Uname: Username of who is actually requesting this data.
DateNow: Function you can use within CS to generate the date and pass it to STRS. You could do this in STRS as well.
Target: Target node of what the user has requested to export
Email: Email address of the CS user populated by “LL_UserMailAddress /”
CSHost: This is hardcoded to the value of what a basic content server request (to this specific CS) looks like. You do this because in your output, you could build a 2-D barcode that can be scanned and take you to the parent node that is exported all dynamically of course.
4) Once all of that has taken place, you now have a file called output.xml that can be ingested into STRS. Lets have a look at how STRS project is configured.
4a) Platform is basic, just have a dir scanner scanning the directory where [EXP] is outputting the output.xml to.
4b) Message is just XML->Storyteller:
Here is how the event looks and essentially how the output.xml comes out.
Notice the custom fields we added in 3c, Uname, Email, CSHost, DateNow, Target. The Car target translates to 34776 dataID which is a unique identified that CS uses to identify its objects. Then the rest is basically the 4 data elements extracted from the original test.xml, id, Name, objName(what type of object it is) and parentID (what container is it in). Also node the <node> at the top as this is added via my XSL stylesheet not the export. So that gives you more flexibility to make STRS easier to configure. This format is a big change to what the original test.xml that CS generates looks like. A lot of content from here is dropped however you do not need it for this exercise. Here is a short example of what test.xml can look like:
4c) ST process there is nothing to special. Here is an overview of its layout.
4d) Runtime email config:
Here you can see the use the $email variable passed in from CS, into STRS to make sure this data goes to whomever in CS requested the export.
5. Finally, your output that is requested in step 1 via Content Server forms is sent through Content Server workflow and then to STRS. Strs then ingests the XSL formatted XML data and emails the Content Server user something like:
Name: Is actually the username(even though that looks like an email, it is a uname) of the user who requested this data.
QR link: If you were to scan this, it would take you into the node that you exported.
6) After all of this has been completed, using ELS in 5.6 you can then place that same document back into Content Server after it has been rendered via STRS. I will go into a bit of configuration here regarding that.
6a) On my runtime email connector I set archiving up for strs.ECMCCM
6b) Here is how my documentType looks like:
6c) Metadata group:
7 ) A new really great feature of 5.6 is you now can run the document mapping from STRS to ELS via Control Center now using “Document Type Mapping”. This is covered in the “OpenText StreamServe 5.6 Storing documents in Content Server and Archive Server User Guide.pdf” document.
Here is a much better representation without having to use the batch file application for ELS supplied in 5.5. On the left we have the document types available via STRS. On the right, all the document models created in ELS. Once you select a docType and docModel you can then begin to map the fields 1 to 1 very easily. If you keep the name names with the same types, you can use the automap feature which can map all the matching data in one click.
7c) Here is how the connection profile which allows you to use the document mapping tool looks like. This is accessible via CC
7d) To determine where the document goes in CS, I use the ELS archive filter.
You can name the document different for each object processed to ensure you don’t end up with different versions or conflicts. Here the folderID is hardcoded in this case just to make things easier for retrieval.
I have glossed over some details here however this should get you a good start on Content Server integration with STRS, and integrating STRS with ELS in 5.6. Questions or comments just let me know and I am happy to answer as best I can. Enjoy! Happy Archiving!
XSL stylesheet example can be found in document attached.