新会话开始时保存全局属性值 [英] Save global attribute value when new session starts

问题描述

我在SAP Fiori App中有两个字段:Template_ID和Offer_ID.

I have two fields in SAP Fiori App: Template_ID and Offer_ID.

我想根据Template_ID字段值选择Offer_ID中的值.

I want to choose value in Offer_ID depending on Template_ID field value.

为解决此问题，我尝试执行以下步骤:

For solving this problem I've tried to do this steps:

当用户单击后端中的Template_ID字段时，将运行方法:

When the user click on Template_ID field in Back-End runs the method:

CL_CUAN_CAMPAIGN_DPC->contentset_get_entityset().

此方法返回参数et_result.在et_result中，我有必填字段temp_id.

This method has returning paramater et_result. In et_result I have the necessary field temp_id.

为了保存temp_id的值，我在类ZCL_CUAN_CLASS中创建了一个全局属性.

For saving temp_id value I created a global attribute in class ZCL_CUAN_CLASS.

ZCL_CUAN_CLASS=>GV_CONTENT = VALUE #( et_result[ 1 ]-temp_ID OPTIONAL ).

我将这个全局属性用作第二种方法的input参数:

I'll use this global attribute as an input parameter for my second method:

CL_CUAN_CAMPAIGN_DPC->GET_OFFER_BY_TEMPLATE().

此方法向我返回带有offer_id的内部表，该表属于我选择的temp_id.

This method returns to me the internal table with the offer_id, which belongs to my choosen temp_id.

但是，当用户单击Web UI上的Offer_ID字段时，在调试中，我看到我的全局属性为空.

But when the user click on Offer_ID field on Web UI, in debugging I see that my global attribute is blank.

可能是因为会话或其他原因，但它是空白.

May be it's because of session or something else, but it's blank.

推荐答案

OData is a stateless protocol, meaning the server responds your query, then forgets you were ever there. By definition, this does not allow you to transport main memory content from one request to the next.

另一方面，用户界面通常需要状态.可以通过以下选项之一获得它:

User interfaces on the other hand usually require state. It can be gained through one of the following options:

正如豪杰指出的那样，一种解决方案是存储在用户界面中选择的数据，并将其作为过滤条件提交给下一个请求.具有状态用户界面是无状态服务器应用程序的标准解决方案.

As Haojie points out, one solution is to store the data that was selected in the user interface and submit it as a filter criterion back to the server with the next request. Having a stateful user interface is the standard solution for stateless server apps.

另一种选择是将数据永久存储在服务器的数据库中，最好是在ABAP中存储在业务对象中.该对象具有唯一的标识符，可能是GUID，您可以在请求中引用该标识符以标识正在处理的进程.

Another option is to store the data permanently in the server's database, in ABAP preferredly in a business object. This object has a unique identifier, probably a GUID, that you can reference in your requests to identify the process you are working on.

如果不是所有信息都一步一步可用，例如在多步向导中，则不应立即变为活动"状态，或者您希望在进行多步过程时能够切换设备，请草稿是一个选择.草稿是常规的业务对象，其一个特殊之处是它们保持惰性，直到用户触发最后的激活步骤为止.

If not all information is available in one step, such as in a multi-step wizard, should not become "active" right away, or you want to be able to switch devices while working on a multi-step process, drafts are an option. Drafts are regular business objects, with the one specialty that they remain inert until the user triggers a final activation step.

对于性能优化，您可以查看 SAP网关的软状态模式，它使您可以缓冲一些数据，以便能够更快地响应相关请求.不过，通常不建议这样做，因为它与OData的无状态范式矛盾.

For performance optimizations, you can have a look at SAP Gateway's soft state mode, which allows you to buffer some data to be able to respond to related requests more quickly. This is generally discouraged though, as it contradicts the stateless paradigm of OData.

在某些情况下，像OData这样的无状态协议不是正确的选择.例如，银行业务应用程序仍然更喜欢关联状态，以避免用户无限期保持登录状态，从而变得容易遭受CSRF之类的攻击.如果您是这种情况，则应在用户界面上查看ABAP WebDynpro.通常，有状态服务器协议被认为是劣等的，因为它们会长时间绑定大量服务器资源，因此无法处理更大的用户数量.

In some cases, stateless protocols like OData are not the right way to go. For example, banking apps still prefer to pertain state to avoid that users remain logged in infinitely, and thus becoming vulnerable to attacks like CSRF. If this is the case for you, you should have a look at ABAP WebDynpro for your user interface. Generally, stateful server protocols are considered inferior because they bind lots of server resources for long times and thus cannot handle larger user numbers.

这篇关于新会话开始时保存全局属性值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！