在Global.asax中获取Session的注意事项

几年前给朋友珠宝公司开发过一套旺财珠宝库存管理系统,用得还是web Form老技术,但是更多的走Ashx+Ajax,但前端可是HTML5+jQuery+BootStrap等新技术,所以不论功能还是用户体验,都能很完美的满足用户要求(用户才不管你用的是什么技术,先进的和古老的都必须解决他的问题,然后还需要好用)。近期特别反馈说有些页面比较慢,我觉得用了几年了,数据库就近2个G了,可能是数据库查询的问题,也可能是程序执行的问题,也可能用户网络问题。数据库可以在服务器上用Sql Server Profiler进行查询分析,但页面上还得做点跟踪。于是就用Global.asax来实现,本来很方便的,但为了获取当前登录用户,需要在Global.asax中获取Session,花了点时间才搞定,记录下来分享一下。

本来想在Application_BeginRequest或者Session_Start里面获取的,可怎么也获取不到,于是翻看MSDN了解Global.asax的事件及执行顺序,在Application_AcquireRequestState中才获取到。

    protected DateTime StartDateTime;

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        //开始执行时间
        StartDateTime = DateTime.Now;
    }
    protected BaseUserInfo CurrentUserInfo;
    protected void Application_AcquireRequestState(object sender, EventArgs e)
    {
        if (Utilities.UserIsLogOn())
        {
            CurrentUserInfo = Utilities.GetUserInfo();
        }
    }

    protected void Application_EndRequest(object sender, EventArgs e)
    {
        DateTime endDateTime = DateTime.Now;
        TimeSpan ts = endDateTime - StartDateTime;
        //5秒以上的慢页面进行记录
        if (ts.TotalMilliseconds >= 5000)
        {
            StringBuilder sb = new StringBuilder();
            sb.Append("时间:" + endDateTime.ToString("yyyy-MM-dd hh:mm:ss fff") + ",当前请求URL:" + HttpContext.Current.Request.Url + ",请求的参数为:" + HttpContext.Current.Request.QueryString + ",页面加载的时间:" + ts.TotalMilliseconds + " 毫秒");
            if (CurrentUserInfo != null)
            {
                sb.Append(",用户:" + CurrentUserInfo.UserName);
            }
            FileUtil.WriteMessage(sb.ToString(), BaseSystemInfo.StartupPath + "//Log//Slow/" + DateTime.Now.ToString(BaseSystemInfo.DateFormat) + ".txt");
        }

    }

通过上述代码就可方便的获取哪些页面比较慢,何时、何人、何参数、何地(IP)发生的。

2018-05-11 03:33:18 947:[当前请求URL:Modules/WMS/ItemMaster/ItemMasterPlan.aspx;请求的参数为:;页面加载的时间:8151.3672 毫秒]
2018-05-11 04:09:25 181:[当前请求URL:Modules/WholesaleWMS/tools/WholesaleBPStatement.ashx?action=RefreshStatement;请求的参数为:action=RefreshStatement;页面加载的时间:19720.7031 毫秒]
2018-05-11 05:18:10 486:[当前请求URL:Modules/WMS/OutboundOrderLine/OutboundOrderLineListSummary.aspx;请求的参数为:;页面加载的时间:16742.1875 毫秒]

2018-05-12 10:33:59 305:[当前请求URL:Modules/WMS/PurchaseDemand/PurchaseDemandAdmin.aspx;请求的参数为:;页面加载的时间:9375.9765 毫秒]
2018-05-12 10:49:19 497:[当前请求URL:Modules/WMS/ItemMaster/ItemMasterPlan.aspx;请求的参数为:;页面加载的时间:5278.3203 毫秒]
2018-05-12 01:24:36 673:[当前请求URL:Modules/WMS/InboundOrderLine/InboundOrderLineListReport.aspx;请求的参数为:;页面加载的时间:11416.0156 毫秒]
2018-05-12 01:24:42 045:[当前请求URL:Modules/WMS/InboundOrderLine/InboundOrderLineListReport.aspx;请求的参数为:;页面加载的时间:6209.9609 毫秒]
2018-05-12 01:24:42 611:[当前请求URL:Modules/WMS/InboundOrderLine/InboundOrderLineListReport.aspx;请求的参数为:;页面加载的时间:10142.5781 毫秒]
2018-05-12 04:39:35 251:[当前请求URL:Modules/WMS/OutboundOrderLine/OutboundOrderLineListSummary.aspx;请求的参数为:;页面加载的时间:16623.0469 毫秒]
2018-05-12 04:51:31 401:[当前请求URL:Modules/WMS/OutboundOrderLine/OutboundOrderLineListSummary.aspx;请求的参数为:;页面加载的时间:16648.4375 毫秒]
2018-05-12 04:57:15 362:[当前请求URL:Modules/WMS/OutboundOrderLine/OutboundOrderLineListSummary.aspx;请求的参数为:;页面加载的时间:16552.7343 毫秒]

最后附上MSDN上对Global.asax的解释:

按执行顺序来解释一下Global.asax.cs中相应的事件处理方法的含义

  1. Application_BeginRequest:BeginRequest是在收到Request时第一个触发的事件,这个方法自然就是第一个执行的了。
  2. Application_AuthenticateRequest:当安全模块已经建立了当前用户的标识后执行。
  3. Application_AuthorizeRequest:当安全模块已经验证了当前用户的授权时执行。
  4. Application_ResolveRequestCache:当ASP.NET完成授权事件以使缓存模块从缓存中为请求提供服务时发生,从而跳过处理程序(页面或者是WebService)的执行。这样做可以改善网站的性能,这个事件还可以用来判断正文是不是从Cache中得到的。
  5. Application_AcquireRequestState:当ASP.NET获取当前请求所关联的当前状态(如Session)时执行(真是拗口啊,msdn上就这样写的,我自己想不出什么好句子了)。
  6. Application_PreRequestHandlerExecute:当ASP.Net即将把请求发送到处理程序对象(页面或者是WebService)之前执行。这个时候,Session就可以用了。
  7. Application_PostRequestHandlerExecute:当处理程序对象(页面或者是WebService)工作完成之后执行。
  8. Application_ReleaseRequestState:在ASP.NET执行完所有请求处理程序后执行。ReleaseRequestState事件将使当前状态数据被保存。
  9. Application_UpdateRequestCache:在ASP.NET执行完处理程序后,为了后续的请求而更新响应缓存时执行。
  10. Application_EndRequest:同上,EndRequest是在响应Request时最后一个触发的事件,这个方法自然就是最后一个执行的了。

再附上两个无顺序的,随时都可能执行的

  1. Application_PreSendRequestHeaders:向客户端发送Http标头之前执行。
  2. Application_PreSendRequestContent:向客户端发送Http正文之前执行。

开了个区块链的新分类

五一前开始休假,揩政府的油,免费高速回了趟老家。好几天时间远离了电脑,连看手机的时间都很少,看到很多大城市之外的东西,引发了不少思考,对于IT之外的新老事物除了要接触、研究之外,还要真正实践和体验。

加上节后跟好友聚会较多,话题开放。发现很多人都在谈区块链,索性开个新分类,蹭蹭热点,为未来的转型做准备。

好友陈斌是区块链技术和理论的研究和实践者,他开了一个知识星球,目前免费加入,感兴趣的一起加入。

另外,作为实践的第一步,我开始去接触目前区块链最热门的应用:电子货币。已在目前比较知名的火币网平台注册,你有兴趣也一起加入。

有人追随的管理者才叫领导

如果你觉得本文又是一个标题党,但我要是将标题反过来说,你可能就开始认同了:没有人追随的管理者还能叫领导?

我一直用这个思路来观察空降到一个公司的高管,看看有没有继续拉拢曾经的亲信和手下过来。我的结论很简单:如果一个高管,没能有几个下属是跟着干过几年的,那绝对值得怀疑的。

我也一直用这个思路来观察一些中层和基层,是否愿意跟着自己曾经的主管、上司一起跳槽,如果下属愿意跟着,那我觉得这个人是有领导力的,是值得信赖的。

也许这个观点以后很多年会改变,正如你看我的博客会发现以前写得文字很幼稚,跟现在的还相互矛盾,但这丝毫不影响我写下此时此刻的想法。

有个自己开公司的朋友,公司也几十号人了,经常交流和分享我待过的外企的现状、管理制度、理念等。但朋友每次都会诉苦,说员工、主管这不行,那不行的,骂人的话脱口既出。

有次提到一个一手提拔、培养的员工,因为觉得底子太差,实在培养不出来,不能再被重用,犯了一点小错,就借此开掉。我听了很是诧异,于是问他一个简单的问题:你平常开会也会当面训斥员工吗?

答案你们肯定能猜到。我也毫不客气的指出问题,要让公司、团队改变,必须改变从老板开始。外企的管理理念看起来虽好,但不一定适合所有的企业,不一定适合所有的行业,不一定适合所有的团队规模等

还延续刚刚关于开会的话题,我随便网上都可以找到各种开会的技巧、方法,但真正执行的如何?效果又如何?

我们为什么要开会?开会的目的是什么?我们真想想要的是什么?

针对我朋友的情况,只想告诉他,作为老板在会议上的反面形象:如果每次开会都变成老板从上到下的骂员工,不断的指责他们,说这么干下去,我们公司要完蛋了,有多危险。整天说所有人都不上心,我相信很多人逐渐地对于工作都会失去信心,想要去远方。

很多看起来复杂的事,只因为我们忘记本源,丢掉了最基础的东西。

这也是为什么很多管理者,懂得一堆的管理理念,仍然做不好管理。

你的管理或者说领导力有多牛逼一点都不重要,重要的是,你的下属,因为跟随了你变得牛逼。

请记住:有人追随的管理者才叫领导!

 

通过税改,看Infor ERP LN/BaaN的圈子氛围

前面发了2篇关于税改的文章,通过朋友圈发给自己的微信朋友们,同时也斗胆发送到几个自己所在的QQ群,通过各个群的一些反馈,从点滴中看到了目前整个圈子的氛围。

有些QQ群发了之后,就群主表达了欢迎之意,后面就没有人有任何反馈了;而有些群即便是有不少跟帖,但表现出的针锋相对、鄙夷、自信的确让人很费解。因涉及隐私,不便截图,就将一些QQ群的话摘录一下。

这个方案不靠谱,直接在国家税码中增加一个新税率就好,新税率的生效日期为2018-05-01

我的点评:我们不必因为自己公司的特殊应用,或未涉及的应用,而否定了别人的全盘周全考虑。但怀疑和否定的态度值得肯定!

可以直接将系统税码17的税率改成16,后台再修改名字,后台GTM修改名称把17修改为16

我的点评:这明显是IT技术思维,不是业务顾问的思考问题和解决问题的习惯。很多时候我们的确可以通过直接操作数据库来完成一些事情,但不到万不得已不能去用。应对税改的方案应该有很多,如果不放弃自己唯一的“后台思维”,怎能拥抱并拥有除此之外的N多个方案?

能不用后台改表不,我相信上面几个说的方案,运行一段时间后,系统会乱的一塌糊涂。别和我讨论这个话题啊。只有***给出解决方案是基本正确,有部分小瑕疵,不影响大局,其它都是错的。

我的点评:尽管我认同此人的“后台思维”,但并不表示你可以否定它。很多技术或顾问有个不好的习惯,不自觉的就以打击别人来提高自己,但殊不知:杀敌一千 ,自损八百的道理。还有,很多人愿意分享,不一定是因为自己非常强大才有资格分享,如果你真认为自己的方案更好、更完整,请多花点时间分享出来,不要费那么多时间去研究别人写得方案,而最终就是为了评价和贬低别人。

分享一下给我们啊,看不下去了

我的点评:真正的强者是可以接受别人的挑战的,如果自己技术和能力不行,多花点时间脑补,提高功力。激怒强者的结果未必好。但对于自高自大的强者,新人、年轻人其实无需畏惧,当你到了这个年龄,你会做得比他更优秀。智者千虑,必有一失;愚者千虑,必有一得。敢于挑战强者的勇气是需要的!

那些人直接通过GTM改的,是什么脑子哦

我的点评:虽然我也不认同直接GTM修改,但没必要通过这种损人不利己的话来显得自己的很专业,系统是人涉及的,熟悉业务的人,开发过这个系统的人,可以准确无误的仅通过数据库的操作来完成前台正常流程一模一样的数据。这并不为奇,同样我觉得这也是GTM存在的一个原因。

QQ群的交流,随着五一的来临还在持续,明显看出来,很多人看到上述的交流后,跟我有同样的感触,选择静默,继续潜水。

但我大胆呼吁:别人说得不全面,你可以补充;别人说得不对,你可以分享自己的做法;希望不管是甲方、还是乙方,不管是业务用户,还是IT用户,都能拥有包容和尊重的态度。

有一种理想的人际关系叫做:相互欣赏

即便我们做不到,但求同存异,共同发展,应该是我们的一致目标。

感谢你还一直看我啰嗦,那么最后来点干货吧,同时附上一张图,据说看懂得人都是聪明人。

关于采购订单和销售订单的税率的计算,以下是我的测试结果,如有异议,可自行测试。

采购订单上的Tax Amount是根据Planned Receipt Date(应该是Line的,不是Header的)来计算每个订单行所对应的税码在此时间生效的税率。

销售订单上的Tax Amount是根据Planned Delivery Date(应该是Line的,不是Header的)来计算每个订单行所对应的税码在此时间生效的税率。

如上图,5月1日生效的VAT17的税率为16%,那么计算的结果就是

800*0.16=128
43796.24*0.16=7007.49

如果不想批量改Open订单的Tax Code,并且Audit也没问题的话,用这个方法就行。不管你会不会用,反正我会用。

除了截图,我还附上一些代码,是通过Where Used Table Field 找到所有tcmcs032.edat的使用清单,逐个检查代码后找到的一个最简单的应用例子。估计能看此文看到这里的人都能看得懂:

function get.sing.tax()
{
	select	tcmcs032.*
	from	tcmcs032
	where	tcmcs032._index1 = {:tcmcs036.ccty, :tcmcs036.cvat}
	order by tcmcs032._index1 desc
	as set with 1 rows
	selectdo
		tax.rate = tcmcs032.pvat
	selectempty
		tax.rate = 0
	endselect
}

所以,税改的方案,每家公司都可以在自己的测试系统进行一些测试,省得盲信盲从。

比方说测试重点是老订单在新税率启用后,究竟如何操作的问题:你可以创建一些销售订单和采购订单,然后针对那个税码创建一个第二天生效的税率,接着第3天完成采购订单和销售订单的后继操作,看看到底税率和发票的操作有没有问题。

再假如说你要测试退货的问题,你可以选择一个老采购或销售订单,选择在第三天进行操作,就知道问题所在了。

基层、中层和高层,你在哪里?

2年前,网上有一篇很有名的文章《任正非的用人之道:砍掉高层手脚,中层的屁股,基层的脑袋》,当时以为是标题党,就没仔细看,时至今日,开始研究组织架构,思考企业这个组织中的高效运转问题,才反过来去好好读了几遍,有种错过了几百万的感觉。

任何组织都由有不同的层次的个体组成,企业更不例外。中国人不是经常说:道生一、一生二、二生三、三生万物吗?那么如果硬要将企业里的员工分层次,3个层次就可以概括了:一个叫底(基)层,一个叫中层,还有一个叫高层。

底(基)层:看责任心,有执行力,短期利益,工资和加班费
中层:看进取心,有理解力,中期合作,提成和奖金
高层:看事业心,有决断力,长期合作,股票和期权

为什么我有上述的总结呢,源于观察和思考。一味追求“器”的提高,边界永远在“术”的范畴。停下来思考,复盘,然后放空,才能跳出边界,重新出发。

你在哪里不重要,关键是你想去哪里?

重磅:增税改革Infor ERP税率调整方案及相关税务处理建议

自4月12日《制造业增值税降低,Infor ERP LN中税率调整的注意事项》发布后,我一直等待着Infor官方的消息,至今未看到。但可喜的是看到来自拓创,这家圈内很有名气的Infor ERP咨询顾问公司的一篇公众号文章,介绍LN和BaaN 4的调整内容和修改方案,还有政策解读和财务层面需要多注意的事项,真得要赞一个。

忍不住贴一张图,更多详情请访问:《增税改革Infor ERP税率调整方案及相关税务处理建议

一段思考,鼓励自己,也希望可以帮助到一些人

近期跟10多年前就就久仰大名,加了电话到通讯录,却从未谋面的BaaN圈内知名人士、创业者熊宇,终于有了第一次面对面交流。其学业和职业的发展经历甚是与众不同,更加不同的,可以说是独特的是其创业的初心、对企业的定位、人生的理解。短暂相聚,未能尽兴,虽说几个小时的聊天,那些紧张、惊险、曲折又生动的经历足可以写一篇上万字的杂记,但我觉得还是需要去花更多时间,去写一篇关于他的更加专业的人物访谈。今天就写点,通过此次交流,带给我一些新的思考。

如果你无路可走,你会拼命寻找出路;

如果你只找到1条路,你会毫不犹豫的走下去;

但如果你有2条路可走,你一定会犹豫,到底选择走哪条路好。

成功一定有方法,失败一定有原因。

成功者的道路都是相似的:想法 》行动》挣扎》突破》成功

大多数人在挣扎过程放弃,放弃的原因不是真的坚持不住了。

是禁不住诱惑,转行了。

我们都会犯这样的错误,得不到的永远是最好的,其他行业都比我们从事的好。

做.NET遇到瓶颈了,发现当下Java工资更高,PHP更流行,Python更热门,就转型了。

做Infor LN /BaaN ERP,发现SAP不错,Oracle不错,干了没几年就放弃LN了。

做传统制造业太压抑了,没啥前景,互联网行业自由发展快,跳槽去做互联网了。

做了之后才发现到处是坑,然后就像兔子一样在各个不同领域跳来跳去,想找一个没坑的,工资高的,升职快的,赚钱容易的,直到一事无成。

机会越多不代表越好,最难的是保持专注,我过去10多年随接触领域和行业颇多,也做了不少尝试,大家可以通过博客了解到,但我的职业从未离开过Infor LN/BaaN ERP,从未离开.NET,未离开Web,从未离开制造业企业信息化。

虽然我积累的速度慢,但在这2个领域,再持续努力个几年,加上中国制造2025的到来,我相信届时不成为此方面的专家、大牛也难。

就像熊宇所创立的指北,从2001年的13家BaaN咨询顾问公司,到如今全中国才只有3-5家。大浪淘沙,现在还在坚持着的,本身就已经是成功。我很感谢熊宇所说的一句话:你能坚持10多年在写博客,本身就是中国Infor LN/BaaN ERP自媒体传播第一人了。

不管这句话是否是恭维,但我相信,从这个月初我重新定位博客和Infor ERP LN私房菜知识星球,并提出这个目标开始,我已经走在路上。无非是坚持的问题了。

我认为:自媒体的能带给大家的最大价值就是传播价值,虽然我可以创作有价值的分享,但去传播那些乐于分享的人、以及其自己的经历、经验、闪光点,才更有价值。

我相信:只有自己相信,才能更可信,才有人愿意追随、愿意支持你。

再次恭喜:王芳兴先生荣登2018首席信息官峰会上海站个人奖榜首

先上图吧,今天的主角是下图中第一位,再次恭喜,实至名归!

王芳兴是我第一家外企上海马可文化用品公司(目前已更名并在国外上市)的直线汇报IT经理,我加入后刚满1个月,他就转去主抓生产做厂长,但还兼管IT,虽然在马可只有1年零3个月的相处时间,但至今深受其影响。
记得当时有一阵感觉到工作上没啥压力,也无思进取,下了班就出去玩、打球、喝酒吃饭、唱歌,被其揪住谈心,一顿严肃批评,当时的意思我理解下来应该是:如果你感觉工作没有压力、没有挑战时,没有方向和更高的目标,也不会花出下班的时间去琢磨、去研究,说明你停留在原地踏步。可能他早已忘记当初的谈话,但对我的影响至今犹在。
特别感谢当初他招聘我入外企,并从单纯的Web开发,转而接触ERP系统,并持续搞ERP至今。更重要的是,当时他营造了很单纯和温暖的工作和成长环境,让每一位IT成员都能融洽的相处,并发挥各自所长。至今我们几个其当时的部下,依然在微信群里与其保持着交流。

以下是其参加活动的公开信息,特转载如下:

2015-至今,任上海盘古餐饮管理有限公司 CIO兼供应链副总裁,致力于传统餐饮连锁企业的新零售创新实践和供应链变革。

2011-2014年,任星巴克中国信息技术总监,成功实施了星享卡会员系统、星礼卡储值系统、Web Portal、手机APP、电子券、电子商务等数字化营销项目,发展会员1600W+;成功实施了门店WiFi项目,使星巴克成为中国零售门店无线上网的代名词。

2007-2011年,任味千中国信息技术总监,成功实施了集团的JDE ERP系统、门店POS和BOH等系统,是味千中国IT的奠基人。

1997-2006,任上海马可文化用品公司总裁助理,负责信息系统和工厂制造。在1998年成功实施了中国文化用品行业的第一套ERP系统;并于2005年第一个在中国文化用品行业成功实施精益生产系统。

对于味千中国星巴克大家都很熟悉,可能这个盘古餐饮不熟悉,但是如果我说出来其旗下的品牌,在上海的朋友想必都去吃过:Pankoo釜山料理、新石器烤肉、川域、酩悦炭烧火锅、毕真烤肉集市。

言归正传,除了光环之外,还是着重看一下其参加评选的创新与实践吧!

盘古餐饮“高效店铺”的创新与实践
通过与外部团队2年多的共创、研发,在新石器烤肉近200家门店成功实施了悍码云POS系统厨房智能出餐(KDS)系统。该系统是基于移动互联网的产品思维设计的,功能强大但简单易用,可快速实施,真正“还系统与业务”;系统打通了外卖、团购、支付和电子发票等平台,实现了“员工在线”、“产品在线”、“顾客在线”、“管理在线”等新零售消费场景,形成了闭环的、持续的数据流;系统上线后6个月内,堂食顾客的手机点单率一直维持在88%以上(全国200家门店平均),并逐步上升,列全国所有大中型餐饮连锁之首;该系统帮助门店大幅提高效率,前后场各节省一个人,可为公司每年节省3000W+的费用。

1、实现了门店IT基础架构的创新,为门店新零售场景下的应用提供了可靠的、不间断、可自动监控的、少维护的IT设施服务。
2、引入钉钉、Teambition、e-Learning、直播平台、番茄表单等工具,大幅提升门店沟通、协同、培训、调研的效率,同时利用在线工具对员工的行为进行分析和管理。
3、通过共创,对门店流失客流进行智能视频分析,帮助门店寻找业务机会点;对门店产品的出品质量进行智能视频稽核,帮助门店提升顾客满意度。
4、在产品售价没有改变的情况下,从去年4季度到今年1季度,实现门店的SPMH(每小时人效)上涨15%,评价满意度上涨5个点。

我相信看我博客的很多朋友来自相对传统的制造业,转载上述介绍的目的是用一种开放的心态,去跨界学习,打破目前信息化的认知边界,反思和尝试其成功的应用和经验。