Dispatcher was earlier known as Translation Management system. It manages translation requests which are coming from Teamcenter user and Dedicated Servers.
Dispatcher is the integration of the Dispatcher Server and Siemens Teamcenter.
Inside Teamcenter, suppose you have secondary dataset PDF which is attached to Item revision and instead of PDF you need format of this pdf data into MS Word. Then, in this case, you are calling .pdf to .doc translator.
We have couple of free s/w which translates .pdf to .doc
Here, Consider you haven’t configured the Teamcenter dispatcher and you have standalone exe, which can translate this .pdf to .doc format then traditionally user does following steps
So, Every time User needs to deal with this lengthy and time-consuming process and imagine if there are hundreds / thousand number of users who used to follow the same procedure which is again time-consuming and its ratio gets double.
For avoiding this, Siemens has provided an option called as dispatcher. Which would automate this whole procedure?
within the single click, you can generate the translated files and dataset inside Teamcenter.
Following table shows the old and new name of Dispatcher modules
The dispatcher client provides the framework to extract and load data from Siemens Teamcenter.
The dispatcher client provides communication to way the Dispatcher Server components.
The scheduler manages distribution of translation requests across modules.
Scheduler prioritizes each request based on high, medium and low type and it maintains the queue.
Translation tasks are submitted to the scheduler by Teamcenter via Remote method or HTTP communication.
Scheduler information to distribute the translation tasks to manage one by one module running to its best capacity.
The Module folder actual contains all translators. Modular get request ID from scheduler and translate that request and give result back to the scheduler.
All translated files are kept inside the staging area.
The module is used for dispatching the specific translators required for translation tasks. It provides the root for a common way to plug in and purge any translator request and support the distinct command line options, parameters, and configuration files rarely to each translator. The module is a Java-based RMI application.
For each request, random numbered taskid folder gets generated. All results are stored in this folder.
apart from these results few logfiles get stored in this folder. Data get stored depends on the translation request.
After certain interval of time, all completed requests gets deleted from this folder.
The following table shows all statuses of dispatcher request at different point of time.
Lets Discuss Dispatcher in more detail in our upcoming Post.
We will more post on PLM TUTORIAL–>TEAMCENTER in upcoming days.
Kindly provide your valuable comment on below Comment section and also have you any question kindly ask to an ASK QUESTION in FORUM . Our Team will try to provide the best workaround.
Kindly subscribe your Email-Id at (https://globalplm.com/) and drop any suggestion/queries to (globalplm2@gmail.com).
View Comments
Nicely explained in minimum words. Thank you.
Welcome Aniket.
Well explained. Thank you
Welcome. Please subscribe your email in globalplm.com for new update.
It's nice. Thank you,
Always Welcome. For more content kindly login to http://www.globalplm.com
Nice post.
A question: Let's assume 100 users starts the same translation at the same time. How does it handles so many requests?
Does the module creates multiple instances of translator or a single instance would process request one by one?
Good content and self explanatory..
Thank you very much 😊.
Always Welcome.
For more content kindly login to http://www.globalplm.com
Thank you
After reading this explanation about Dispatcher, Now I got full clarity, how the dispatcher works and what was the steps to complete the translation process, explained well in detailed.
Thanks, Global PLM.
Single instance, it will process one by one. because the scheduler manages distribution of translation requests across modules.
Scheduler priorities each request based on high, medium or low type and it maintains the queue.
Single instance, it will process one by one. because the scheduler manages distribution of translation requests across modules.
Scheduler priorities each request based on high, medium or low type and it maintains the queue.