从上周五休假到现在呢，这一周又没啥工作心情，又想着考公务员算了。
唉，话说得，好像公务员好考似的🙄。
人生没啥大起伏，这心情倒是波澜起伏的。心情不好的时候不想工作。
一周大概有四天心情不好，因为有四天都要开会，也不知道开个啥😫😪😴

事情呢，是这样的。现在不是都不用STMS传了么，用solution manager。
就长这个样子：

这个系统呢，不归我们管，归ERP那组的人管。
但是这个呢，就有的时候你传请求，请求传到Q，那出错了，肯定是传不到P里面了。
然后你再新建另外一个请求，成功了，传到P了。
那这个错的。咋办呢。得删掉啊，要不然占地方。
(此处不谈副本传输）
以下不知道是否适用其他公司。

1. SolMan大概概念

1.1 Incident Management

从我们可以创建的东西来看，这个是提给ERP的，就是我们对ERP系统的问题，可能是自己的账号问题啦，一些业务问题啥的

1.2 Change Management

就是developer做更改，然后需要传输的。
一个request for Change 关联到一个特定的Change Cycle
一个RfC呢，一般会有一个Change Document. 如果有多个task，那可能会有多个change documents.
这个CD是干啥的呢？就是Test的结果需要写到CD里，添个附件啥的。



但是实际情况下，咱都没有啥test,自己弄了就传了，没问题就直接到P。

主更改呢，会有一个专门的Change Cycle,需要一个approve的流程。（就是有很多client，但是只在这个主client上更改）这个我也不知道怎么回事。
Sold-to-party 就是最终传的系统。

2. 如何清理积压的ticket

2.1 已完成

如果状态是“successfully tested”或者“authorized for production”,或者“pre-import”那就表示，这个请求已经传到Q上了，那就没话说了，该做的更改已经做了，下一步就传呗。如果传到P上有错误，或者有些技术性问题，那就再分析。
CD：“successfully tested/preliminary import”–>“authorized for production”–>completion–>confirm
CD:“authorized for production”->analyze transport/queue,solve problem and complete deployment/afterwards confirm RfC

2.2 刚创建

还没传输的，看看是否需要了，不需要的话，直接撤回。withdraw。
RfC: “Created/To be validated/approved” --> withdraw
CD: Created–>withdraw–>withdraw the RfC

2.3 在进行中，将会完成

“in development”或者“to be tested” 看是否需要了，如果需要那就继续进行。

2.4 在进行中，将会被撤回

这种已经有CD或RfC的传输请求，那你得首先把这个transport给清空，或者删除，或者Decoupled(解耦）然后才能撤回。
这个就是标题上我们讨论的，已经传到Q了，那其实这里涉及到一个概念。
就是一般情况下，大家都不太在意这个Q系统。因为Q就是个测试，定期会从P复制到Q，确保Q和P系统的一致性。

你做的更改如果已经传到Q了，但是不需要传到P，你如果担心下次搞的D和P的内容不一样，那你就在这个请求下再新建一个task,通过SCU0或SCMP在D和P上做对比，把D和P弄得一样，然后再传到Q上，或者传到P上也行。用STMS传就行了。这样系统的东西就一样了。

另外由于这个CD在solution manager上已经是successfully tested,那你就可以把它转成 in development,就算transport已经到Q了，但是你切回in development后，可以用个program: RDDIT076，把released掉的请求改为modified，然后删掉transport里面的内容，再decouple这个request，就可以withdraw这个CD了。

过期请求的处理

如果change manager说不要了，就在change document里面写下原因。
如果这个CD不包含任何transport，直接withdraw CD和RfC
如果包含transport但是不包含任何objects，withdraw CD和RfC
如果这个transport 有对象：

• 把tester改成自己
• 如果CD 是to be tested 改成 in development
• 加一个新task到这个transport里（这个transport的owner得是你，不是的话改成自己）
• 用这个transport来恢复已做的更改或者开发
  - 和P系统做下对比，确保别把P系统已有的更改给覆盖掉（用这两做对比SCU0/SCMP）
  -standard change: 处理Solman的CD，不是做test，而是加个note进去，说你做了个恢复。然后改状态到 successfully tested.
• 这个状态改完咱都知道，下一步transport management会自动给你传到Q。
• -Local Complex Change：这个我没做过，但是和standard change一样，改到“authorized for production”
• 然后这个transport会自己走正常流程
• master change:和local complex一样，只不过要通知下service manager，每个公司都不一样吧。
  

3.如何处理新的请求

首先有个容易混淆的点，就是你新建的时候，是建一个Request for Change（RfC)，而且这个requestor 和manager不一样，当这个被approve了之后，那就会有一个Change Document,这个是要分配给implementer 和 tester的。