Quantcast
Channel: SCN : All Content - BOPF Application Framework
Viewing all 309 articles
Browse latest View live

BOBF Transaction Manager in status "Finished"

$
0
0

Hello,

 

i am writing a scenario test in ABAP and face a problem with the transaction manager.

 

I face this problem

METHOD switch_callstack_state.

 

   " if the current transaction state is "finished" (after having saved with Save&Exit Pattern),

   " no more service manager usage is allowed

   IF mv_transaction_state = gc_state_finished.

     set_application_error( ).

   ENDIF.


CleanUp does not work. What can i do to get a new transaction manager instance?


Thank you


Christian Scheffel


ABAP to the future – my version of the BOPF chapters, part 5 - Properties

$
0
0

8.2.6 – Restricting meaningful BO-interaction using properties

In the book “ABAP to the future”, this chapter is named slightly different: “Disabling certain commands using validations”. This original title mixes two actually different aspects which should – in my opinion – clearly be separated: Action validations and action properties. As this is a common misunderstanding, I will dedicate this chapter to properties and handle validations in the next one.

As written in the book, it is of interest for a consumer, whether an interaction with some business entity is possible (e. g. whether a button can be pushed or not). Similarly, there is good reason that some attribute should not be visible or displayed only read-only: The interaction, that this attribute can be changed shall not be allowed. This is “disabling in advance to the actual interaction” is particularly relevant for a human consumer. Usually, the business logic which is being executed when deciding about whether a button shall be enabled or not is a subset of the checks which are being executed before the action would be performed. For example, we could enable the button which makes a monster howl at the moon only for monsters with heads. In addition, when trying to howl at the moon, it shall be verified that if the monster is a werewolf, the current time is a full moon. If the user asks a werewolf to howl at other times, an error message shall be created (but no howl). As this werewolf-specific check (“validation” in the BOPF terminology) is quite special, it is better with respect to user experience to explain the impossibility to the user using a message instead of just disabling the button: The user who is not handling werewolves daily would not be able to understand why the button is not enabled. Thus, in BOPF, there are different mechanisms for both aspects: While validations actually verify the requested interaction with or the state of an instance, properties are an additional mechanism to implement business logic which helps to avoid impossible interactions by a human consumer. Consequently, there is an own core-service “retrieve properties” which allows to execute this business logic.

The core-service “retrieve properties” is an optional channel for a user interface in order to request information about limitations of interactions with a BO instance (precisely with the instance of a BO node).

Multiple aspects of the model can be subject to properties (there are some few more than listed below, but they are most likely not relevant for your business and would be really tricky to explain):

  • Actions: Whether the action is enabled (usual visualization: Button is active or grayed out)
  • Node attributes:  
    • Enabled (usual visualization: Field is hidden from the UI if not enabled)

    • Read-only (usual visualization: Field is changes from input-field to text-label)
    • Mandatory (usual visualization: Field is highlighted, e. g. with an asterisk)
  • Nodes: Delete enabled (usual visualization: The delete-button is hidden if not delete enabled)
  • Association: Create enabled (usual visualization: The new-button in order to create a sub-node in a tabular control is de-activated if not create enabled)

Properties can either be statically modeled (e. g. the hat-size-code shall always be read-only, as it’s being determined from the hat-size) or they can be dynamically determined through a property-determination. We’ll do the latter now for our action to howl at the moon.

Implementation of a property-determination

A property-determination is a particular configuration of a determination (we’ve been covering that in the previous chapter). As all kinds of determinations, the implementation is an ABAP-class implementing the determination interface /BOBF/IF_FRW_DETERMINATION.

The interface methods CHECK and CHECK_DELTA are or no relevance in this case, as there’s no “change” when retrieving properties, so let’s directly head to the EXECUTE-method.

METHOD /BOBF/IF_FRW_DETERMINATION~EXECUTE.

* Technically, properties are captured at runtime in a technical subnode (which we don’t have to model explicitly). A helper class facilitates the handling of this subnode (sadly to be constructed directly)

DATA lo_set_property TYPE REF TO /bobf/cl_lib_h_set_property.

CREATE OBJECT lo_set_property
EXPORTING
  is_context = is_ctx “ Determination context
  io_modify   = io_modify. “ Reference to modify object

DATA lt_root TYPE ZMONSTER_T_ROOT. “The combined table type of the node to be retrieved

io_read->retrieve(
exporting
  iv_node = zif_monster_c=>sc_node-root
it_key = it_key
  it_requested_attributes = VALUE #( (zif_monster_c=>sc_node_attribute-root-number_of_heads ) )
importing
  it_data = lt_root ).

LOOP AT lt_root ASSIGNING FIELD-SYMBOL( <ls_root> ).

IF <ls_root>-number_of_heads = 0.

* Disable the action to howl at the moon if no head’s available

lo_set_property->set_action_enabled(
EXPORTING
  iv_key            = <ls_root>-key
  iv_action_key = zif_monster_c=>sc_action-root-howl_at_the_moon
iv_value          = abap_false ).

* Also, the total number of eyes which we calculate as total eyes of all heads is not relevant in this case, let’s disable this attribute (so that a UI knows it can hide it)

lo_set_property->set_node_attribute_enabled(
EXPORTING
  iv_key            = <ls_root>-key
  iv_node = zif_monster_c=>sc_node-root
iv_node_attribute = zif_monster_c=>sc_node_attribute-root-total_eyes
iv_value          = abap_false ).

ENDIF.

ENDLOOP.

ENDMETHOD.

I hope you now got an idea of what properties are and why they should be used in order to determine the potentially meaningful interactions with a node instance. If you’re still in doubt, please do ask!

In the next chapter, we’ll have a look at validations which includes options how to really prevent an interaction.

FBI view with context based adaptation (CBA)

$
0
0

Hi experts,

 

I'm trying to figure out how to use the context based adaptation feature of a FBI view. When you create a FBI view, there is a tab called context based adaptation where you can define CBA schema's and dimensions.  Then using that FBI view for example for a form uibb does not enable the CBA button of the form component configuration.

When I also enable my FPM application for CBA, forgetting the FBI view for a moment, this button is enabled and we can use the CBA schema and dimensions in my form configuration, but then adding the CBA schema to my FBI view seems to be useless.

By debugging class /BOFU/CL_FBI_VIEW_INSTANCE_NEW->HANDLE_CTXT_BASED_ADAPT, the view seems to be missing relevant dimensions.


Can someone explain how this feature of the FBI view should be used?


Thanks in advance!


Kind regards,

Bjorn

ABAP to the future – my version of the BOPF chapters – Part 6: Validations

$
0
0

8.2.7 – Validations

In “ABAP to the future” it is being said that validations in BOPF are meant to check the consistency and prevent saving. This is only partially correct. Validations are those parts of the model which represent idempotent (repeatable without changing the state) checks. When a validation is being executed and what the effect of a failed validation is, depends on the validation’s configuration. In general, there are two types of validation configuration: Action validations and consistency validations. The implementation of both types is based on the same interface (/BOBF/IF_FRW_VALIDATION) and thus, the same implementation class can be used in multiple places. Therefore, I also recommend to restrict the scope of a validation as much as possible in order to facilitate re-use.

Action validations

We still don’t really know what an action is, but we’ll start with action validations.(Actions and action validations will be covered in the next chapter of the book, but I believe it's better to have a chapter on both types of validations as they are so similar. However you might the chapter on actions first, it will be linked here once available.) An action validation is – surprise, surprise – registered to be executed before an action is being executed. If the validation fails, the action will not be invoked for the failed instances. Let’s have a look at a sample which we foreshadowed some chapter ago: The business requirement reads that howling at the moon should only be possible for monsters with at least one head. In addition, werewolves should be able to howl at the moon only if it’s full moon. The two aspects are semantically independent, therefore we create two validations which we both register for the action HOWL_AT_THE_MOON: HAS_AT_LEAST_ONE_HEAD and IS_FULL_MOON. If later on, we might for example add an action BITE, we could also register the HAS_AT_LEAST_ONE_HEAD for it, but not the full-moon-check (assuming that also human-bodied werewolves can bite). This additional configuration would not require a single line of code and makes our model more readable with respect to the pictured business.

The implementation of HAS_AT_LEAST_ONE_HEAD looks very similar to what we coded in the previous chapter’s property determination with one big difference: We now want to prevent the action execution and provide a meaningful error message. Remember: The property-determination was only executed on request of the consumer (the UI-layer).

METHOD /BOBF/IF_FRW_VALIDATION~EXECUTE.

DATA lt_root TYPE ZMONSTER_T_ROOT. “The combined table type of the node to be retrieved

CLEAR: ET_FAILED_KEY, EO_MESSAGE.

io_read->retrieve(
exporting
  iv_node = zif_monster_c=>sc_node-root
it_key = it_key
  it_requested_attributes = VALUE #( (zif_monster_c=>sc_node_attribute-root-number_of_heads ) )
importing
  it_data = lt_root ).

LOOP AT lt_root ASSIGNING FIELD-SYMBOL( <ls_root> ).

IF <ls_root>-number_of_heads = 0.

* Get a message container. Unfortunately, the message container is not injected as a handler, so we must instantiate it actively. #architectural_fail

IF eo_message IS INITIAL.

eo_message = /bobf/cl_frw_factory=>get_message( ).

ENDIF.

* Create a message by instantiating the message-class. Don’t use the instantiation of /bobf/cm_frw_core as written in the book (this is bad style), but simply make your exception-message-class inherit from /bobf/cm_frw. There’s also a blog post about message-objects in BOPF on SCN ;). The constructor-expressions pay-off very well in this case!

eo_message->add_cm( NEW zcm_monster(
textid = zcm_monster=>no_head
severity = zcm_monster=>co_severity_error
symptom = /bobf/if_frw_message_symptoms=>co_bo_inconsistency
lifetime = /bobf/if_frw_c=>sc_lifetime_set_by_bopf
ms_origin_location = VALUE #(
  bo_key = zif_monster_c=>sc_bo_key
  node_key = zif_monster_c=>sc_node-root
  key = <ls_root>-key ) ) ).

* The message just created is not meant to be interpreted at all, neither by the framework nor by a consumer. What really matters (and what makes the framework not execute the action in case of an action validation) is the indication of the instance as failed

INSERT VALUE#( key = <ls_root>-key ) INTO TABLE et_failed_key.

ENDIF. “monster has no head

ENDLOOP.

ENDMETHOD.

The validation code will always be executed if the action to howl at the moon is about to being performed or if the core-service “check_action” is being executed by a consumer: In this case, all action validations configured for the requested action will be executed. In contrast to what’s being said in the book, there is no option to invoke a particular validation.

Consistency validations

A consistency validation is a check which is being executed as a side-effect of an interaction with a business object changing the state of one or multiple instances (without a change of its state, the consistency of the instance cannot change anyway). As such, the configuration of a consistency validation is comparable to the configuration of a determination: You can select trigger nodes and modification (CUD). Additionally, all consistency validations which have been configured on “check” are being executed through the core-service check_consistency. While an action validation prevents the action if it fails, the consistency validation’s reaction on failure is defined by a so-called “consistency-group”: Either it can prevent saving or it can set a consistency-status (which is a dedicated node-attribute). The latter is particularly interesting if you think about stateless-applications in which a save is effectively being requested after each round-trip: The framework will mark the instance as inconsistent if a consistency validation fails on save. With a new stateless request, this consistency-status can be interpreted in order to prevent a subsequent action which should only be possible for consistent instances.

With respect to implementation, there’s no difference compared to action validations (both implement the same interface). But as consistency-validations are being executed as a result of a modification (which – once again – the consistency validation will not prevent), there’s good reason to also implement the check and check_delta-methods, which don’t make much sense for action validations. I will not provide a complete implementation now (you can read one in “ABAP to the future”), but I want to point out some of the major mistakes made (which you unfortunately can also find in the book):

  • As all interface-methods, also the validation methods are mass-enabled! If you ever see a READ INDEX 1 in BOPF code, this will most probably not work in mass-scenarios.
  • Most of the BOPF framework-classes (containg _frw_ in their names) are meant to be instantiated by the framework only. You should not reference those classes or instantiate them directly. General advice: Program to the interface, not to the implementation. Usually, either/bobf/cl_frw_factory will have a method providing you a proper instance or you will get it injected at runtime (so it’s available as an importing-parameter, such as the io_read and io_modify).
  • For message-classes or libraries, inheritance is a common reuse-mechanism in BOPF.
  • In addition, all the pitfalls mentioned in the chapter on determinations apply – including the lengthy “no need for a single model class”-pledge.

About raising exceptions

As you might have noticed, the signature also features an exception of type /BOBF/CX_FRW which can be raised and you may wonder whether it would not be suitable for failed validations. The short answer: No, it is not. The system will go for a (“controlled”) short-dump. I could also go for a long explanation why this is desired, but I fear no-one is really interested in reading it. If you would like to know more about it, please comment

Determination attribute assignments

$
0
0

Hi,

 

I was wondering how the attribute assignment checkboxes of the request nodes for a determination work. Can these checkboxes be used to define which attributes have to be changed to trigger the determination?

 

Determination attributes.PNG

 

When I test this it seems that changing attributes which are not selected (e.g. currency) also trigger the determination.

 

In the determination's check_delta method, we can use io_read->compare method to retrieve the changed attributes.  Is it possible to retrieve the selected attributes of the determination's configuration instead of having them hard coded? I've tried with the following, but I don't find the selected attributes this way.

 

DATA(lr_nd_conf) = /bobf/cl_frw_factory=>get_configuration( iv_bo_key = is_ctx-bo_key ).      lr_nd_conf->get_node(        EXPORTING iv_node_key = is_ctx-node_key IMPORTING es_node     = DATA(ls_node) ).

Thanks in advance!

 

KR,

Bjorn

Is a key locked (without locking it)?

$
0
0

Hi,

 

Does BOPF provide a method that returns for a set of keys (for one specific node) the information which keys are locked without actually locking the keys?


Regards, Thomas

/bobf/cl_frw_factory=>get_message with error Don´t Stop process?

$
0
0

Hi experts.

 

I'm working with Determinations when i go SAVE data in NWBC.

 

I used a message error to validate duplicate data;

 

*------------------------------------------------------------

             lv_message-msgty = 'E'.

             lv_message-msgid = 'ZTM_BLOCK_NFE'.

             lv_message-msgno = '001'.

 

             IF eo_message IS NOT BOUND.

               eo_message = /bobf/cl_frw_factory=>get_message( ).

             ENDIF.

 

             eo_message->add_message(

               is_msg  = lv_message

               iv_node = is_ctx-node_key

               iv_key  = ls_key-key

                ).

*------------------------------------------------------------

 

This message is showed correctly in NWBC screen but don't stop the save process like se91 class messages.

I need to stop the save process when show this message error.

 

How can i Do it?

Thanks.

Search help in Determination to NWBC field screen.

$
0
0

Hi Experts.

 

I created a field in NWBC screen and I want put a search help for this field.

Could I call a search help function inside my Determination for this field ?

 

For example when i want to block a field i use:

  lo_property->set_attribute_read_only(

              EXPORTING

               iv_attribute_name = 'ZPACKTYPE'

               iv_key            = ls_item-key

               iv_value          = abap_true ).


And it works.


But when I want input a search help with data selected in my validation and dont know how do it.


do you  know how to do it?Or  do you know  a page in sap TM guide that teach it.?



Thanks


Want to trigger BASIC_INFO_ALL Update on Saving The ROOT EHHSS_INCIDENT

$
0
0

I need to determine some values for the custom fields I have added to the PERSISTENT Include of the SUB-NODE - BASIC_INFO_ALL of the ROOT Node of EHHSS_INCIDENT.

 

I have added the code to DETEREMINATION for BASIC_INFO_ALL Subnode.

 

This code gets triggered when I make a change or update to the BASIC_INFO_ALL Node in the NWBC client ( Incident Recording ).

 

However I would also like to trigger the determination for BASIC_INFO_ALL when the ROOT Node is Updated.

 

I have gone through this discussion Assigning default values to root and subnode attributes

But it is a discussion about custom nodes.

 

On my part using transaction /o/BOBF/CONF_UI I have checked the following boxes

 

EHSS_INCIDENT-BASIC_INFO_ALL-Determination.JPG

 

However when I go to activate my changes the system considers my changes as a MOD and asks me for an access Key.

 

Is there any other way to achieve what I am trying to do?

 

Please suggest.

Index on Alternative key for a database table is missing or incorrect error

$
0
0

Hi,

 

i created an alternate key and also define the index of the Root database table by selecting the alterbate key but still i get the error when i go a syntax check on my BO.

please could you let me know why this happens.

 

Thanks

MGR

BOPF on HANA

$
0
0

Hi Gurus

 

If I want to make use of BOPF on HANA how do I do this.

 

I understand it is incorporated into Netweaver so it should be possible, correct?

 

Regards

 

Panduranga

Access to Representation Node via ABAP

$
0
0

Hi to everyone,

 

how do I access to the content of a representation node?

 

I've created a representation node referencing another existing custom business object (I have followed the instructions found in Thea Hillebrand's document Defining Associations with Business Object Builder eXpert and I can retrieve correctly the data of the representation node when testing it with the BOBT transaction, so I guess I got the configuration right). I'm trying to retrieve the node data using io_read->retrieve_by_association from inside an action defined in the root node of the host business object but I'm getting an unhandled exception.

 

io_read->retrieve_by_association(

  exporting iv_node = is_ctx-node_key

            it_key = it_key

            iv_association = zhost_bobj=>sc_association-host_root-repr_node

            iv_fill_data = abap_true

  importing et_data = lt_repr_node_data ).

 

 

Where lt_repr_node_data's type is the combined tabletype of the node referenced in the representation node.

 

I also found Aiko Schmalle's approach (Accessing a delegated object in BOPF), which it's actually related to delegated nodes and not to representation nodes but anyway I tried it... with no success either.

 

Sorry if this has been already answered, but I really have searched for it and haven't found anything.

 

Regards,

A.

One truth, multiple views on it: The various BOPF modeling environments

$
0
0

One particular thing which always causes a headache for BOPF-newbies is the multitude of tools which can be used in order to model a business object.

Therefore, I would like to give a brief overview and explain their dedicated purpose and powers. But before we head there, let me explain one elementary thing:

One (Meta-) Model (instance)

No matter with which tool you change the configuration, it will the same model which is getting manipulated. Precisely, the model of your business object is an instance of a model of business objects, the so-called “meta-model” (model of models). What is funky about it: also the meta-model is built with BOPF as a business object. The technical name of the meta-model is /BOBF/CONF_MODEL. As such it features plenty of nodes capturing the model information (such as – well – your business object’s nodes or the configuration of your validations) as well as a lot of business logic which is getting executed as you interact with the meta-model through one of the modelling environments. One of the strengths of BOPF is that the business logic is independent of the UI, so no matter your weapon of choice, the business object will (technically) look the same afterwards. You could even use the test-UI (BOBT), load business object /BOBF/CONF_MODEL and model your monster business object. But I recommend you not to do that, there are more comfortable modeling UIs. Let’s look at them from oldest to latest.

 

The full-blown SAP-internal workbench (BOBF, /BOBF/CONF_UI)

The so-called “Conf-UI” is THE almighty tool for modifying every aspect which the BOPF BO model covers (whether you call this “modelling” or “configuration” (of a meta-model-instance) is a matter of personal liking). However, SAP is not too confident about the usability of the transaction and obviously scared of the potential need of support if customers use all the options. E. g. it has turned out that – although technically possible – the buffer-class for each node should not be changed: The buffer-classes provided by SAP do a decent job and, what’s more important, fulfill the quite complex contract. Options like these should be hidden from customer’s eyes (or fingers, to be precise).

Therefore, the complete transaction is an SAP-internal tool and editing Business Objects or creating new ones is not possible in the Conf-UI. Unless you set a Set-Get-Parameter (Paul has already disclosed this in “ABAP to the future”, but I won’t do this here as well): Whatever you do in this mode is not supported by SAP and I urge you not to do that!

 

2015-09-02 12_19_49-A05(1)_001 Business Object Processing Framework (for internal use only).png

 

2015-09-02 12_14_52-A05(1)_001 Display Business Object ZMONSTER, Active Version.png

The Conf-UI allows to model a lot of unsupported features (such as multiple node categories), especially some options on the menu. Don’t use it unless you want to do some research on the full power of BOPF (no productive use).

 

For the supported set of features, a limited version of the Conf-UI exists:

The Business object Builder, Expert version (BOBX)

BOBX essentially is a Conf-UI in which all the unsupported features are hidden while offering the option to create custom business objects from scratch. I highly recommend using the BOBX wherever possible.

 

2015-09-02 12_28_21-.png

Some supported features are hidden in the standard view. Switch to the extended view  in order to be able to e. g. specify a custom database access class.

 

 

If your business object does not behave the way you expect it to, you can always create an OSS-ticket and benefit from the brilliant and very helpful (no irony here!) BOPF support. And do believe me: They immediately see if you tweaked your business object with the Conf-UI. However, if there is some model-feature you’re missing, you might check the full-fledged version and explain to the BOPF-team in a ticket why you think this should be available in the BOBX as well.

 

2015-09-02 08_40_58-ABAP - A05_001_db1695e_en - Eclipse Platform.png

The BOBX limits the the features which can be modeled to the supported features

BOPF in Eclipse (BiE)

If you’re already using ABAP in eclipse, you also might want to model your business objects within the same workbench. And you can. The only thing you need to do is to remember to install the proper plugin in your eclipse installation. It’s available in the same repository as ABAP in eclipse. BiE has a different paradigm than the previous two: It offers not only less, but more powerful modeling options which are then translated to the basic model elements. Due to usability and the integration into the modelling environment, even the first version of BiE is worth a look.

 

Aie.png

BOPF in eclipse: Lots of navigation options (blue) and a usecase-driven detail screen (in red)

 

2015-08-31 13_28_38-.png

BiE detail: Powerful breadcrumbs-navigation

 

2015-08-31 13_29_28-ABAP - Business Object ZMONSTER [A05] - Aktiv - A05_001_db1695e_en [A05, 001, DB.png

Sample of BiE: An action configuration including the trigger actions.

 

You can even switch between the BOBX and the BiE, but be careful not to edit with the Conf-UI: You will not be able to switch to the released tools once you saved your object in BOBF.

 

The BOBF enhancement workbench or the BO builder (/BOBF/CUST_UI, BOB)

BOPF configurations can be extended – with BOPF configurations. This basically means that the enhancement is some business object which relates to the extended BO. At runtime, BOPF will merge the BO with its extensions so that it behaves like a single one. However, only a limited set of features can actually be extended.

 

bob.png

The BO builder has much limited features (those necessary for enhancement) and displays entities from all nodes. Recommendation: Use BOBX for custom objects instead.

 

The BO builder allows to navigate the host object in a similar way like the Conf-UI or the BOBX. Also in BOB it is possible to create custom business objects, but the features offered are much reduced compared to the BOBX. Recently, BOBX was also enabled to model extensions, so in my opinion, there’s no need to use BOB at all.

 

Verdict

Use BOBX if your development environment is the SAPGui, if you have move to ABAP in Eclipse, use the Eclipse-based editor. Keep your hand off the Conf-UI though it might be tempting to use it.

Get click event Screen.

$
0
0

Hi experts.

 

I have been  working with determination with bopf.

 

My Determination is called in all modification screen.

 

I need it be called only when the user click in a nwbc menu option specific.

 

How can i know what menu is clicked by the user to put in my code?

If i need create a event to menu please send a tutorial.

I have a TM guide but i didnt find how to do it.

 

For example in sap ecc the abap use sy-ucomm but how to do it in bopf inside a determination?

 

 

Thanks.

What are the differences between Query and Retrieve in BOPF?

$
0
0

Hi,

i would like to know the differences between query and retrieve. I heard that query hits  db and Retrieve hits buffer.


Create enabled on Cross BO association

$
0
0

Hi,

 

I have a BO XYZ which has a cross BO association to BO ABC. the scenario is "Create enabled". i.e After creating the BO XYZ node instances i would like to create instance on the BO ABC based on the predefined logic.

 

This is resolution by target node.

 

i came to know that cross bo association is not create enabled. ("When i navigate in BOBT to the cross BO i don't see the create button enabled").

 

from my analysis there could be two approaches

 

1. i create an action on BO XYZ to create the instance in ABC. This action should be called automatically after the instance on the BO XYZ is created. for this i call action from the determination.

 

2. Implement an association class on the cross BO modeled association and implement the CREATE target instance.

 

please can you let me know what is the standard here/correct me if am wrong?


Thanks

MGR

Text Collection tabs for Schedule - Departure and Departure rule

$
0
0

Dear Experts,

 

I got a requirement mention below

 

 

  • When a departure rule/ departure is selected the option to enter texts will be
    presented to the user similar to the functionality in objects such a Freight
    Order at Item level (screenshot below)

 

FOR.PNG

 

In the same way requirment is to get three tabs visible , each tab has a text input with the text type where user can insert the text based on stages selection from derparture and departure rule tab. When user selects one stage line these tab should be visible and user can enter the text in text content of each tab. Could you all please suggest how to acheive this requirement.

 

I have gone through one blog which says to create delegate node  please suggest.

 

Regards.

Transporting some table entries to another system

$
0
0

Hi everybody,

 

I have a table generated by BOPF.

The key of the table is:

MANDT type MANDT

DB_KEY type /BOBF/CONF_KEY

 

You can see this is just normal for a BOPF table.

 

What I want is to transport some records of this table to another system. (target)

Normally I would put an entry in the transport like below:

R3TR TABU    <TABLE_NAME>

And provide a key.

 

But the field DB_KEY is of type RAW and I can’t provide it as a key in the transport.

The only option is to use * as the key, but I can’t do that because that will delete entries in the target system that are not in the source system.

 

My question is how to transport some entries of a BOPF table to another system. All entries is also ok, but in the target system no entries may be deleted.

 

Thanks in advance.

How to create a determination for a transient node

$
0
0

Hi

 

We need to display Z information from TOR into the Planning Cockpit. To do that, we've inserted a ZZ field at the TORFU node of /SCMTMS/PLN BO.

 

Now, we need to fill our Z field with some data, and that´s precisely our issue: we are trying to create a determination for TORFU, using option "Fill transient attributes of persistent nodes", because option "Derive instances of transient nodes" is not available at the moment when I try to create the determination.

 

After clicking on the Complete button, nothing happens: the determination is not created (I guess that´s because TORFU is not a persistent node). Would someone have a clue on how to solve this problem?

 

Regards

Eduardo Chagas

ABAP to the future - my version of the BOPF chapters - Part 1 Addendum: Other associations

$
0
0

8.1.4 Other associations

You have probably guessed that there are other ways of nodes being associated with each other than compositions. Let’s have a look at them as they kind of define the static structure of a business object model.


Modeled intra-BO-Associations

Nodes of the same business object might have more than one relationship. Above I wrote about heads of a monster which have a certain function or a specific feature.

These dedicated heads would still be heads (and not a separate  node in the model), but could be represented by an own association from ROOT to HEAD. There could be an association “preferred head” (with a cardinality 1) or “heads with hats” (with cardinality 0..*). As long as this can be expressed as a static restriction (with a “where-clause”), BOPF supports to model this association. Select the source node of the association and use the context-menu to create a new one.

image001.jpg

Figure 7 - Basic properties of each association



While “cardinality” and “associated node” are easy to understand, the “resolving node” migt need an explanation: This information defines at which of the two nodes the information resides (as some kind of foreign attribute) which can be used in order to resolve the association. For unbound cardinalities, this usually is the target node, for cardinalities 1 this may be the source node.

The mapping of attributes between the nodes can be done on the “association binding” tab. But before we do that, we have to select a pattern (don’t just go and enter the binding straight ahead, the pattern is an essential model information, although unluckily not shown).

The following patterns are most common:

·         Specialization: The association selects a set of instances from the composition matching a particular, mostly static criterion

·         Foreign key-relation: There is an equality of some node attributes between the source and the target node. The association shall find the ones which match (just like a FK-relation in DB-tables). Note that in order to do this, an alternative key needs to be modeled at the resolving node. We’ll look at alternative keys later, keep in mind that the cardinality of the association and the alternative key need to match.

Let’s have a look at modelling a specialization:

image002.jpg

Figure 8 - Using binding patterns to define the resolution of an association


We’ll select all the specialized heads which wear hats. Thus, in addition to the criterion that this node instance is a subnode-instance (PARENT_KEY = KEY), we’ll add a static filter criterion.

image003.jpg

Figure 9 - Adding a constant binding for a specialization association


The filter value has to be taken from a constant interface. This is in general a good idea, I recommend to create one for your BO anyway containing all the domain values of the node’s attributes. Unluckily, BOPF does not support structured constants for filter variables, thus my constant interface looks like this:

image004.jpg

Figure 10 - Only unstructured constants can be used for a constant binding


Modeled cross-BO-associations

Associations may also associated nodes from other business objects. In order to do this, a so-called “representation node” needs to be created. You can imagine this node being the anchor of the other bridge to the other business object in the source BO. With the representation node, BOPF automatically creates a Cross-BO-association with the same name for which you just have to provide a binding.

There is a limitation with respect to the attribute binding: Foreign keys used in cross-BO-associations may only consist of a single attribute. Usually, this is the GUID containing the source node’s KEY.

Note: At runtime, these associations must be resolved using a service manager, not via the read-interface. Just keep this in mind, although you might not understand this sentence yet.


Implemented associations

For each association (no matter whether intra- or cross-BO), you can also provide an implementation (/BOBF/IF_FRW_ASSOCIATION) which is used for resolving the links between the source and target node. This should only be used if there’s no other option for expressing the relationship (e. g. if you need to join additional data to the target node in order to get it resolved or if the association is based on transient data).

From a consumption point of view, all of these associations behave equally. The consumer will not know whether an association is a modeled or implemented association. They all return pairs of source- and target-key.


> Find more alternative versions of chapters in my blogs.

Viewing all 309 articles
Browse latest View live