Windchill listener

listener

Слушатель в Windchill.

На днях пришло такое письмо:

Интересует такой вопрос. У нас созданы свои подтипы частей (наследники wt.part.WTPart) со своими атрибутами, иконками и т.п. Характерный признак который разделяет эти части это РАЗДЕЛ СПЕЦИФИКАЦИИ (LEVEL_SP):
3 — Сборочные единицы
4 — детали
….
8 — комплекты
В EPM документе модели Pro/ENGINEER так же присутствует данный параметр. Но когда мы сдаем его на хранение и выбираем «Создать части автоматически» то естественно создается обычная часть wt.part.WTPart. Нам бы хотелось, чтобы создавалась та часть, которая соответствует нужному типу. Решение представляется нам в виде какого-то небольшого кода на JAVA, но пока глубоко не лазили в систему, не знаем как реализовать.

В качестве решения возможно не самого лучшего предлагаю следующее:

Создать в Windchill сервис слушатель который будет программно менять тип у созданной части,
единственное неудобство у части появляеться еще одна итерация, метод будет срабатывать для всех частей,
а не только создаваемых из ProE.

Windchill позволяет создавать программных слушателей на различные системные события.
Если очень простым языком то можно выполнить произвольный java код после событий наследуемых от класса

wt.events.KeyedEvent

а это:

AccessControlEvent, AdministrativeDomainManagerEvent, BaselineServiceEvent, ChangeService2Event, ContainerTeamServiceEvent, ContentServiceEvent, DeleteManagerEvent, EffGroupAssistantEvent, EffServiceEvent, EPMDocumentManagerEvent, EPMWorkspaceManagerEvent, ESIResultEvent, FolderServiceEvent, IBADefinitionServiceEvent, IdentityServiceEvent, LockServiceEvent, ObjectGraphServiceEvent, OccurrenceEvent, PersistenceManagerEvent, wt.router.RoutingEvent, SessionIterationEvent, StandardManagerServiceEvent, TeamServiceEvent, VersionControlServiceEvent, WorkInProgressServiceEvent, wt.inf.container.WTContainerServiceEvent

Что для этого необходимо проделать

1. Созадть свой класс наследуя StandardManager,
написать тело метода protected void performStartupProcess() throws ManagerException {
скопировать его в Windchill\codebase 🙂

2. Добавить в файл Windchill\codebase\wt.properties описание сервиса, например в моем примере
класс называеться NewPartServiceListener, тогда нужно добавить следующее описание:

wt.services.service.12020=ext.fvg.NewPartServiceListener/ext.fvg.NewPartServiceListener

цифру 12020 нужно брать по порядку в соответствии с максимальным номером это просто идентификатор,
чтобы не пересечся со стандартными лучше прибавить 1000.

3. Перезапусть Windchill

package ext.fvg;

import wt.fc.PersistenceHelper;
import wt.fc.PersistenceManagerEvent;
import wt.part.WTPart;
import wt.services.ManagerException;
import wt.services.ServiceEventListenerAdapter;
import wt.services.StandardManager;
import wt.session.SessionContext;
import wt.session.SessionHelper;
import wt.util.WTException;
import wt.util.WTProperties;
import wt.vc.wip.WorkInProgressHelper;
import wt.vc.wip.WorkInProgressServiceEvent;
import wt.vc.wip.Workable;

import com.ptc.core.foundation.type.server.impl.TypeHelper;
import com.ptc.core.meta.common.TypeIdentifier;
import com.ptc.windchill.enterprise.copy.server.CoreMetaUtility;

/**
* @author Feofilov Ivan created: 29.04.2011
*
*/
public class NewPartServiceListener extends StandardManager {

public static NewPartServiceListener newNewPartServiceListener()
throws WTException {
NewPartServiceListener instance = new NewPartServiceListener();
instance.initialize();
return instance;
}

protected void performStartupProcess() throws ManagerException {
/* Standard debug output */

/* Standard way to become admin */
SessionContext prev = SessionContext.newContext();
try {
SessionHelper.manager.setAdministrator();
} catch (WTException wte) {
System.err
.println(«StandardListenService: failed to set Administrator (ok if installation)»);
return;
} finally {
SessionContext.setContext(prev);
}
/* Change: Add event listeners here */
getManagerService().addEventListener(
new ServiceEventListenerAdapter(this.getConceptualClassname()) {
public void notifyVetoableEvent(Object event)
throws WTException {
// start listener logic———————————
final Workable target = ((WorkInProgressServiceEvent) event)
.getOriginalCopy();
if (target instanceof WTPart) {
System.out.println(«start listener work»);
if (!WorkInProgressHelper.service.isLocked(target)) {
try {
WTPart part = (WTPart) wt.vc.wip.WorkInProgressHelper.service
.checkout(
target,
wt.vc.wip.WorkInProgressHelper.service
.getCheckoutFolder(),
null).getWorkingCopy();
String types = WTProperties
.getLocalProperties()
.getProperty(
«TYPE_FOR_NEW_PART_SERVICE_LISTENER»);
TypeIdentifier tii = TypeHelper
.getTypeIdentifier(types);
part = (WTPart) CoreMetaUtility.setType(
part, tii);
PersistenceHelper.manager.save(part);
wt.vc.wip.WorkInProgressHelper.service
.checkin(part, «»);

} catch (Exception e) {
e.printStackTrace();
}
}
}
// finish listener logic———@@@@@@@@@@@@@@@@@@@@@@@
}
},
WorkInProgressServiceEvent
.generateEventKey(PersistenceManagerEvent.POST_STORE));

}
}

Windchill listener: 3 комментария

  1. Если часть создается на основе EPM документа (модели) то она наследует его атрибуты, в том числе и LEVEL_SP (Раздел спецификации).
    Если же часть создается вручную, то для типов, которые определили мы (наследников WTPart ) атрибуты заданы, и LEVEL_SP для каждого типа уже имеет нужное значение.
    А для непосредственно типа WTPart атрибуты мы не создавали.
    Дело в том, что к примеру у типов «Детали» и «Стандартные изделия» разное количество атрибутов, и нам не хочется добавлять их все к типу WTPart заведомо оставляя часть пустых. Кроме того, на каждый подтип мы назначили свои ионки — так будет намного нагляднее в структуре изделия.
    А для «Прочих изделий» у нас свой жизненный цикл и потоки, которые должны выполняться только для данного типа.

Добавить комментарий