U8 供需政策 查询语句
U8 供需政策 查询语句
select cSRPolicy AS '供需政策' from Inventory where cInvCode in (物料号)
U8 供需政策 查询语句
select cSRPolicy AS '供需政策' from Inventory where cInvCode in (物料号)
我通过几个采用 CSocket 类编写并基于 Client/Server (客户端 / 服务端)的网络聊天和传输文件的程式 ,在调试这些程式的过程中,追踪深入至 CSocket 类核心源码 SockCore.cpp , 对于CSocket 类的运行机制可谓是一览无遗,并且对于阻塞和非阻塞方式下的 socket 程式的编写也是稍有体会。
阅读本文请先注意 :
• 这里的阻塞和非阻塞的概念仅适用于 Server 端 socket 程式。
• socket 意为套接字,他和 Socket 不同,请注意首字母的大小写。
说明:客户端和服务端的通信简单来讲:服务端 socket 负责监听,应答,接收和发送消息,而客户端 socket 只是连接,应答,接收,发送消息。此外,如果你对于采用 CSocket 类编写 Client/Server 网络程式的原理不是非常了解,请先查询一下( 详见:参考书籍和在线帮助 )。
在此之前,有必要先讲述一下: 网络传输服务提供者, ws2_32.dll , socket 事件 和 socket window 。
1. 网络传输服务提供者(网络传输服务进程), Socket 事件, Socket Window
网络传输服务提供者 ( transport service provider )是以 DLL 的形式存在的,在 windows 操作系统启动时由服务进程 svchost.exe 加载。当 socket 被创建时,调用 API 函数 Socket (在 ws2_32.dll 中), Socket 函数会传递三个参数 : 地址族,套接字类型 ( 注 2 ) 和协议,这三个参数决定了是由哪一个类型的 网络传输服务提供者 来启动网络传输服务功能。淘宝开店所有的网络通信正是由网络传输服务提供者完成 , 这里将 网络传输服务提供者 称为 网络传输服务进程 更有助于理解,因为前文已提到 网络传输服务提供者 是由 svchost.exe 服务进程所加载的。
当 Client 端 socket 和 Server 端 socket 相互通信时,两端均会触发 socket 事件 :
这里仅简要说明两个 socket 事件 :
FD_CONNECT: 连接事件 , 通常 Client 端 socket 调用 socket API 函数 Connect 时所触发,这个事件发生在 Client 端。
FD_ACCEPT :正在引入的连接事件,通常 Server 端 socket 正在接收来自 Client 端 socket 连接时触发,这个事件发生在 Server 端。
网络传输服务进程 将 socket 事件 保存至 socket 的事件队列中。
此外, 网络传输服务进程 还会向 socket window 发送消息 WM_SOCKET_NOTIFY , 通知有 socket 事件 产生,见下文对 socket window 的周详说明:
调用 CSocket::Create 函数后, socket 被创建。 socket 创建过程中调用 CAsyncSocket::AttachHandle(SOCKET hSocket, CAsyncSocket* pSocket, BOOL bDead) 。该函数的作用是:
a. 将 socket 实例句柄和 socket 指针添加至 当前模块状态 ( 注 1 )的一个映射表变量 m_pmapSocketHandle 中。
b. 在 AttachHandle 过程中,会 new 一个 CSocketWnd 实例 ( 基于 CWnd 派生 ) ,这里将这个实例称之为 socket window ,进一步理解为他是存放所有 sockets 的消息池 ( window 消息),请仔细查看,这里 socket 后多加了一个 s ,表示创建的多个 socket 将共享一个 消息池 。
c. 当 Client 端 socket 和 Server 端相互通信时 , 此时 网络传输服务进程 向 socket window 发送消息 WM_SOCKET_NOTIFY ,需要说明的是 CSocketWnd 窗口句柄保存在 当前模块状态 的 m_hSocketWindow 变量中。
2. 阻塞模式
阻塞模式下 Server 端和 Client 端之间的通信处于同步状态下。
在 Server 端直接实例化 CSocket 类,调用 Create 方法创建 socket ,然后调用方法 Listen 开始侦听,最后用一个 while 循环阻塞调用 Accept 函数用于等待来自 Client 端的连接,如果这个 socket 在主线程(主程式)中运行,这将导致主线程的阻塞。因此,需要创建一个新的线程以运行 socket 服务。
调试跟踪至 CSocket::Accept 函数源码:
while(!Accept(...))
{
if (GetLastError() == WSAEWOULDBLOCK) // The socket is marked as nonblocking and no connections are present to be accepted.
PumpMessage(FD_ACCEPT);
else
return FALSE;
}
他不断调用 CAsyncSocket::Accept ( CSocket 派生自 CAsyncSocket 类)判断 Server 端 socket 的事件队列中是否存在正在引入的连接事件 - FD_ACCEPT (见 1 ),换句话说,就是判断是否有来自 Client 端 socket 的连接请求。
如果当前 Server 端 socket 的事件队列中存在正在引入的连接事件, Accept 返回一个非 0 值。否则, Accept 返回 0 ,此时调用 GetLastError 将返回错误代码 WSAEWOULDBLOCK ,表示队列中无所有连接请求。
注意到在循环体内有一句代码:
PumpMessage(FD_ACCEPT);
PumpMessage 作为一个消息泵使得 socket window 中的消息能够维持在活动状态。
实际跟踪进入 PumpMessage 中,人生感悟发现这个消息泵和 Accept 函数的调用并不相关,他只是使非常少的 socket window 消息(典型的是 WM_PAINT 窗口重绘消息)处于活动状态,而绝大部分的 socket window 消息被阻塞,被阻塞的消息中含有 WM_SOCKET_NOTIFY 。
非常显然,如果没有来自 Client 端 socket 的连接请求, CSocket 就会不断调用 Accept 产生循环阻塞,直到有来自 Client 端 socket 的连接请求而解除阻塞。
阻塞解除后,表示 Server 端 socket 和 Client 端 socket 已成功连接, Server 端和 Client 端彼此相互调用 Send 和 Receive 方法开始通信。
3. 非阻塞模式
在非阻塞模式下 利用 socket 事件 的消息机制, Server 端和 Client 端之间的通信处于异步状态下。
通常需要从 CSocket 类派生一个新类,派生新类的目的是重载 socket 事件 的消息函数,然后在 socket 事件 的消息函数中添入合适的代码以完成 Client 端和 Server 端之间的通信,和阻塞模式相比,非阻塞模式无需创建一个新线程。
这里将讨论当 Server 端 socket 事件 - FD_ACCEPT 被触发后,该事件的处理函数 OnAccept 是怎么进一步被触发的。其他事件的处理函数如 OnConnect, OnReceive 等的触发方式和此类似。
在 1 中已提到 Client/Server 端通信时, Server 端 socket 正在接收来自 Client 端 socket 连接请求,这将会触发 FD_ACCEPT 事件,同时 Server 端的 网络传输服务进程 向 Server 端的 socket window (CSocketWnd )发送事件通知消息 WM_SOCKET_NOTIFY , 通知有 FD_ACCEPT 事件产生 , CsocketWnd 在收到事件通知消息后,调用消息处理函数 OnSocketNotify:
LRESULT CSocketWnd::OnSocketNotify(WPARAM wParam, LPARAM lParam)
{
CSocket::AuxQueueAdd(WM_SOCKET_NOTIFY, wParam, lParam);
CSocket::ProcessAuxQueue();
return 0L ;
}
消息参数 wParam 是 socket 的句柄, lParam 是 socket 事件 。这里稍作解释一下, CSocketWnd 类是作为 CSocket 类的 友元类 ,这意味着他能访问 CSocket 类中的保护和私有成员函数和变量, AuxQueueAdd 和 ProcessAuxQueue 是 CSocket 类的静态成员函数,如果你对友元不熟悉,请迅速找本有关 C++ 书看一下友元的使用方法吧!
ProcessAuxQueue 是实质处理 socket 事件 的函数,在该函数中有这样一句代码:
CAsyncSocket* pSocket = CAsyncSocket::LookupHandle((SOCKET)wParam, TRUE);
其实也就是由 socket 句柄得到发送事件通知消息的 socket 指针 pSocket :从 m_pmapSocketHandle 中查找(见 1 )!
最后, WSAGETSELECTEVENT(lParam) 会取出事件类型,在一个简单的 switch 语句中判断事件类型并调用事件处理函数。
在这里,事件类型是 FD_ACCEPT ,当然就调用 pSocket->OnAccept !
本文的结束:
Server 端 socket 处于阻塞调用模式下,他必须在一个新创建的线程中工作,防止主线程被阻塞。
当有多个 Client 端 socket 和 Server 端 socket 连接及通信时, Server 端采用阻塞模式就显得不适合了,应该采用非阻塞模式 , 利用 socket 事件 的消息机制来接受多个 Client 端 socket 的连接请求并进行通信。
在非阻塞模式下,利用 CSocketWnd 作为所有 sockets 的消息池,是实现 socket 事件 的消息机制的关键技术。
文中存在用词不妥和可能存在的技术问题,请大家原谅,也请批评指正,谢谢!
注:
1. 当前模块状态
用于保存当前线程和模块状态的一个结构,能通过 AfxGetThreadModule() 获得。 AFX_MODULE_THREAD_STATE 在 CSocket 重新定义为 _AFX_SOCK_THREAD_STATE 。
2. socket 类型
在 TCP/IP 协议中, Client/Server 网络程式采用 TCP 协议:即 socket 类型为 SOCK_STREAM ,他是可靠的连接方式。在这里不采用 UDP 协议:即 socket 类型为 SOCK_DGRAM ,他是不可靠的连接方式。
学习VC++时经常会遇到链接错误LNK2001,该错误非常讨厌,因为对于编程者来说,最好改的错误莫过于编译错误,而一般说来发生连接错误时,编译都已通过。产生连接错误的原因非常多,尤其LNK2001错误,常常使人不明其所以然。如果不深入地学习和理解VC++,要想改正连接错误LNK2001非常困难。
初学者在学习VC++的过程中,遇到的LNK2001错误的错误消息主要为:
unresolved external symbol “symbol”(不确定的外部“符号”)。
如果连接程序不能在所有的库和目标文件内找到所引用的函数、变量或标签,将产生此错误消息。一般来说,发生错误的原因有两个:一是所引用的函数、变量不存在、拼写不正确或者使用错误;其次可能使用了不同版本的连接库。
以下是可能产生LNK2001错误的原因:
一.由于编码错误导致的LNK2001
1.不相匹配的程序代码或模块定义(.DEF)文件能导致LNK2001。例如, 如果在C++源文件内声明了一变量“var1”,却试图在另一文件内以变量“VAR1”访问该变量,将发生该错误。
2.如果使用的内联函数是在.CPP文件内定义的,而不是在头文件内定义将导致LNK2001错误。
3.调用函数时如果所用的参数类型同函数声明时的类型不符将会产生LNK2001。
4.试图从基类的构造函数或析构函数中调用虚拟函数时将会导致LNK2001。
5.要注意函数和变量的可公用性,只有全局变量、函数是可公用的。静态函数和静态变量具有相同的使用范围限制。当试图从文件外部访问任何没有在该文件内声明的静态变量时将导致编译错误或LNK2001。
函数内声明的变量(局部变量) 只能在该函数的范围内使用。
C++ 的全局常量只有静态连接性能。这不同于C,如果试图在C++的多个文件内使用全局变量也会产生LNK2001错误。一种解决的方法是需要时在头文件中加入该常量的初始化代码,并在.CPP文件中包含该头文件;另一种方法是使用时给该变量赋以常数。
二.由于编译和链接的设置而造成的LNK2001
1.如果编译时使用的是/NOD(/NODEFAULTLIB)选项,程序所需要的运行库和MFC库在连接时由编译器写入目标文件模块, 但除非在文件中明确包含这些库名,否则这些库不会被链接进工程文件。在这种情况下使用/NOD将导致错误LNK2001。
2.如果没有为wWinMainCRTStartup设定程序入口,在使用Unicode和MFC时将得到“unresolved external on _WinMain@16”的LNK2001错误信息。
3.使用/MD选项编译时,既然所有的运行库都被保留在动态链接库之内,源文件中对“func”的引用,在目标文件里即对“__imp__func” 的引用。如果试图使用静态库LIBC.LIB或LIBCMT.LIB进行连接,将在__imp__func上发生LNK2001;如果不使用/MD选项编
译,在使用MSVCxx.LIB连接时也会发生LNK2001。
4.使用/ML选项编译时,如用LIBCMT.LIB链接会在_errno上发生LNK2001。
5.当编译调试版的应用程序时,如果采用发行版模态库进行连接也会产生LNK2001;同样,使用调试版模态库连接发行版应用程序时也会产生相同的问题。
6.不同版本的库和编译器的混合使用也能产生问题,因为新版的库里可能包含早先的版本没有的符号和说明。
编程时打开了函数内联(/Ob1或/Ob2),但是在描述该函数的相应头文件里却关闭了函数内联(没有inline关键字),这时将得到该错误信息。为避免该问题的发生,应该在相应的头文件中用inline关键字标志内联函数。
8.不正确的/SUBSYSTEM或/ENTRY设置也能导致LNK2001。
解决方法:
解决外部符号错误:_main,_WinMain@16,__beginthreadex
在创建MFC项目时, 不使用MFC AppWizard向导, 就会在编译时产生很多连接错误, 如error LNK2001错误, 典型的错误提示有:
libcmtd.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@
msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex
1. Windows子系统设置错误, 提示:
libcmtd.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
Windows项目要使用Windows子系统, 而不是Console, 可以这样设置:
[Project] --> [Settings] --> 选择"Link"属性页, 在Project Options中将/subsystem:console改成/subsystem:windows
2. Console子系统设置错误, 提示:
LIBCD.lib(wincrt0.obj) : error LNK2001: unresolved external symbol _WinMain@控制台项目要使用Console子系统, 而不是Windows, 设置:
[Project] --> [Settings] --> 选择"Link"属性页
3. 程序入口设置错误, 提示:
msvcrtd.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@通常, MFC项目的程序入口函数是WinMain, 如果编译项目的Unicode版本, 程序入口必须改为wWinMainCRTStartup, 所以需要重新设置程序入口:
[Project] --> [Settings] --> 选择"Link"属性页, 在Category中选择Output, 再在Entry-point symbol中填入wWinMainCRTStartup, 即可
4. 线程运行时库设置错误, 提示:nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __beginthreadex
nafxcwd.lib(thrdcore.obj) : error LNK2001: unresolved external symbol __endthreadex这是因为MFC要使用多线程时库, 需要更改设置:
[Project] --> [Settings] --> 选择"C/C++"属性页, 在Category中选择Code Generation,再在Use run-time library中选择Debug Multithreaded或者multithreaded
其中, Single-Threaded 单线程静态链接库(release版本)
Multithreaded 多线程静态链接库(release版本)
multithreaded DLL 多线程动态链接库(release版本)
Debug Single-Threaded 单线程静态链接库(debug版本)
Debug Multithreaded 多线程静态链接库(debug版本) )
Debug Multithreaded DLL 多线程动态链接库(debug版本)
单线程: 不需要多线程调用时, 多用在DOS环境下
多线程: 可以并发运行
静态库: 直接将库与程序Link, 可以脱离MFC库运行
动态库: 需要相应的DLL动态库, 程序才能运行
release版本: 正式发布时使用
debug版本: 调试阶段使用
网上有关SUBMIT实现程序调用的例子稍显复杂,而相关的参考和解释则不是很完善。本文给出一个SUBMIT的小示例程序(代码见文末),实现了最简单的程序间调用及返回值,以及SAP官方文档中相关内容的翻译、解释。
本文链接:http://www.cnblogs.com/hhelibeb/p/5802398.html
转载请注明
SUBMIT {rep|(name)}
[USING SELECTION-SCREEN dynnr]
[VIA SELECTION-SCREEN]
[USING SELECTION-SET variant]
[USING SELECTION-SETS OF PROGRAM prog]
[WITH SELECTION-TABLE rspar]
{ [WITH sel1 { {{EQ|NE|CP|NP|GE|LT|LE|GT} dobj [SIGN sign]}
| {[NOT] BETWEEN dobj1 AND dobj2 [SIGN sign]}
| {IN rtab} }]
[WITH sel2 { {{EQ|NE|CP|NP|GE|LT|LE|GT} dobj [SIGN sign]}
| {[NOT] BETWEEN dobj1 AND dobj2 [SIGN sign]}
| {IN rtab} }]
... }
[WITH FREE SELECTIONS texpr]
[LINE-SIZE width]
[LINE-COUNT page_lines]
{ [EXPORTING LIST TO MEMORY]
| [TO SAP-SPOOL SPOOL PARAMETERS pri_params
[ARCHIVE PARAMETERS arc_params]
WITHOUT SPOOL DYNPRO] }
[[USER user] VIA JOB job NUMBER n]
[AND RETURN].
在CRM中的用户界面对象类型的帮助下,我们可以做这些工作:
一个用户界面对象类型之下会有设计对象的集合,每个设计对象可以控制BOL对象的属性。
第一步,
创建一个回调类。前往事务SE24并且创建一个新类。这个类应该实现接口IF_BSP_DLC_OBJ_TYPE_CALLBACK.
让我们制作一个新的用户界面对象类型。进入SPRO事务中的以下路径,在下一个屏幕选择“新条目”。
按下图的内容填充条目,保存。
回调类用于提供子对象类型,子对象类型可以用于创建视图配置。类名填入在上面创建已经的类,稍后实现方法。
接下来我们将在服务订单上使用这个用户界面对象类型,填入通用组件名(BT)。
BTOrder是BT组件中的主要根对象。
BOR类型BUS2000112代表服务订单类型。保存条目。
我们已经创建了新的用户界面对象类型。在下一步,需要在这个新用户界面对象类型中创建一个设计对象。
在事务SPRO中进入以下路径: 客户关系管理->UI框架->用户界面框架定义->设计层->定义设计类型。
需要输入UI组件类型,填入已创建好的那个。
点击“新条目”,输入以下信息并保存该条目。
保存了条目之后,在当前屏幕左侧点击“设计”,将会打开一个新窗口。
点击新条目,在下一个屏幕按下图填如数据。
这里我想要控制BTAdminH的OBJECT_ID属性,因此选择了OBJECT_ID。
如果需要的话,在“链接到业务对象层”标签下,我们可以填入另一个任意的BOL对象和它的组件。
我添加了新的字段标签,如果选择HIDDEN,这个字段将不会在任何配置中可用(不会在视图的配置标签的可用部分展示出来)。
也可以把特定的字段做成下拉栏或者复选框,如果这个字段包含某些通过在ABAP字典中选择中了“值帮助”复选框而存在的值范围。(细节待会再说)。数据条目完成后,保存条目。
我们准备好了用户界面对象类型和设计对象。下一章中,将通过基本条目BTAdminH把它分配给需要的上下文节点。