In this article you will learn:

Reading time: 8 minutes

Introduction

During implementation of an AIF Interface it can happen that some additional logic needs to be added before or after mapping is being done, but still before action processing. Then Init Function Before Mapping and  Init Function Before Processing comes to help us.

To define any of those functions go to: /AIF/CUST and then: Interface Development->Define Interfaces

After choosing the interface you can provide Init Function Before Mapping and / or Init Function Before Processing, depending on your needs.

Init Function Before Mapping

You can use this function module to modify or manipulate the data in the source and destination structures before the mapping defined in the AIF is executed.

The function module you use here must have the same signature as the template function module /AIF/FILE_TEMPL_INIT_MAPPING.

The best way to create a correct object is to copy provided template function module /AIF/FILE_TEMPL_INIT_MAPPING into the new one:

This way you assure that the function is having the correct signature.

By default your module will be created with a BREAK-POINT inside, which you can use for testing purposes and remove afterwards.

You can manipulate both – destination (“DATA”) and source (“RAW_STRUCT”) structures. Because the template provided by SAP is general-purpose and can be used with all interfaces, those parameters won’t have the predefined structure. Depending on what data you want to manipulate, it is required that you specify the correct data type of the source and destination structures in the newly created function module.

After the logic is implemented and the new function module is active we need to add it to the Interface.

To configure this functionality go to:

/AIF/CUST and then: Interface Development->Define Interfaces , choose your interface and provide the name of your custom FM in the field below.

And that’s it. You have just configured Init Function Before Mapping.

Init Function Before Processing

You can use this function module to modify or manipulate the data in the destination structure after mapping defined in the AIF is executed, but before the processing of the actions starts in the SAP. The init function is processed at the beginning of an action call.

The function module you use here must have the same signature as the template function module /AIF/FILE_TEMPL_INIT_PROCESS.

To create a correct object copy provided template function module /AIF/FILE_TEMPL_INIT_PROCESS into your own one:

This way you assure that the function is having the correct signature.

The same, like for Init Function Before Mapping,  by default your module will be created with a BREAK-POINT inside, which you can use for testing purposes and remove afterwards.

For Init Function Before Processing you can only manipulate destination (“DATA”) structure. It will not have a predefined structure as well, so it is required that you specify the correct data type in the newly created function module.

After the logic is implemented and the new function module is active we need to add it to the Interface.

To configure this functionality go to:

/AIF/CUST and then: Interface Development->Define Interfaces, choose your interface and provide the name of your custom FM in the field below.

And that’s it. You have just configured Init Function Before Processing.

Use cases and summary

Now, when you know how to configure this functionality,  you would probably like to know some examples of the use-cases for both types of functions.

Init Function Before Mapping can be used when:

Init Function Before Processing can be used when:

The use-cases I gave are just an example and they will vary depending on the project and requirements. But they can be a good point in better understanding of the capabilities of those functionalities.

Summary

Now, you are ready to use the  Init Function Before Mapping and  Init Function Before Processing in your AIF projects.

Want to learn more about SAP AIF? Check other articles about SAP AIF on Int4 blog.

Read also:

1. SAP AIF – How to create Interface Variants

2. Set up interface in SAP AIF Interface Monitor (/aif/ifmon)

The post SAP AIF – Using Init Function Before Mapping and Init Function Before Processing appeared first on INT4.

In this article you will learn:

Reading time: 4 minutes

Introduction

The topic of initial setup or SAP AIF Interface Monitor (/AIF/IFMON) was covered by my colleague Mateusz Nowak in his blog. As a follow up I wanted to give a brief introduction to the SAP AIF Interface Monitor and a few of its features that are easily overlooked. Oftentimes, SAP AIF Interface Monitor feels less useful then SAP AIF Monitoring and Error (/AIF/ERR) handling tool especially when looking for a quick way to troubleshoot an interface problem. However in the long run it may be beneficiary to spend some time familiarizing yourself with SAP AIF Interface Monitor and treat it as your starting point for SAP AIF activities. It helps organize monitoring and error handling process as a whole and better manage day-to-day interface maintenance tasks among team members.

I won’t be getting into details on every element of the SAP AIF Interface Monitor, instead I will focus on certain features which usefulness can be easily overlooked.

Dates selection

Mail notification management

Message Summary report

Details and Processor Assignment

My Messages report

Read also:

1. Set up interface in SAP AIF Interface Monitor (/aif/ifmon)

2. /AIF/ERR ? AIF Monitoring and Error handling

3. SAP AIF – How to create Interface Variants

The post SAP AIF Interface Monitor (/AIF/IFMON) – useful features you might have overlooked appeared first on INT4.

Let me introduce my guests

My today’s interlocutors committed their ideas to paper on “Interface Monitoring and Error Handling with SAP AIF”. Wojciech Eichertan SAP Integration Consultant, Krzysztof Łuka SAP Integration Architect and Mateusz Nowak SAP Integration Consultant are Int4’s IFTT, PI/PO, CPI and ABAP experts. As we are colleagues, I will be more personal here and describe the three of them as great, humble, professional, very likeable integration experts.

Erasing all the sweetness from the previous sentence 😉  this piece talks about the main benefits of unification of interface monitoring and error handling, distinction between SAP AIF and SAP PO or CPI, biggest challenge in the SAP AIF, AIF flexibility and relation between business and AIF – Wojciech Eichert, Krzysztof Łuka, Mateusz Nowak are interviewed by Jarosław JZ Ziółkowski.

Reading time: 6 minutes

1. Even though I wanted to start with a less standard question, I cannot help myself asking about the intentions. Why, oh why 🙂 … What made you Krzysztof decide to tackle the “Interface Monitoring and Error Handling with SAP AIF” area?

Krzysztof: When companies decide to implement SAP AIF, the Monitoring and Error Handling is usually the first thing they look at. This is the quick win, the low hanging fruit, that they can get from SAP AIF. With low effort they can benefit from unification of interface monitoring and error handling, and gain more visibility of their interfaces.

So we decided to pick this topic as we thought it would be helpful to have those parts described in one place.

2. Companies decide to implement … Let’s elaborate a little bit more on that. What effect has SAP AIF exactly made on the companies?

Krzysztof: It makes you rethink how your interfaces are designed. There should be a clear distinction between SAP AIF and SAP PO or CPI, and the roles that they play in your integration setup. SAP AIF gives you ability to put all of the business related logic of your interfaces there, and focus on other parts, like connectivity, structural conversions or routing in the middleware. That makes the design of interfaces more structured and easier to handle in the future. In addition, SAP AIF also unifies the way you do monitoring and error handling of interfaces in SAP application systems. Because only then you have one tool to cover all the interfaces that are coming in and out of your SAP application, instead of needing to monitor each interface in a different monitor, depending on the technology.

3. We have covered the business side with Krzysztof and it just automatically goes in my head to the other side and check what effect SAP AIF has made on the integration consultants. Mateusz, could you take this one, please? (laughter)

Mateusz: The biggest effect that SAP AIF makes on the integration consultants is the unified way of working with different integration technologies. For instance, if you are working with IDocs and Proxies, monitoring and error handling has to be done in separate transactions, the way of working with those transactions and UI is totally different. Once you have SAP AIF in place, everything can be monitored from one, single transaction, regardless of the technology. Moreover, the way interfaces are developed is also simplified, because most of the technologies follow exactly the same rules and patterns, so once you learn how to work with SAP AIF once – you can leverage it for most supported technologies. Last, but not least, for most of the cases it’s almost immediately known whether the issue is business or technical oriented and by the same the ping-pong between different departments is reduced to minimum.

4. Oh, it all sounds as if that was a piece of cake. Is it? Really? There must be some challenge involved  when it comes to the SAP AIF implementation?

Mateusz: At the very beginning when SAP AIF is implemented it’s important to describe its architecture very well. It should be understood not only by technical consultants, but also by business consultants. If it’s not done properly it may lead to misunderstandings. Good example of above is the fact that when you use AIF runtime you can get rid of most of the user exits before the final action is done (e.g. before the sales order gets posted with the standard process function module in SAP AIF action). Let’s stick to the example of sales orders. Thanks to moving logic from user-exit (e.g. customer determination based on some tables and logic before sales order is posted) in SAP AIF you can see the original value and the one after mapping. So the challenge here is to make sure that the logic that can be done in SAP AIF – should be done there. Otherwise, there’s no clear picture where exactly the issue occurs – AIF or user exit logic and it slows the error handling process.

5. I would like to create a twist in the plot with this one a bit. (laughter) Wojciech, what kind of question would you like to hear yourself an answer to, in the AIF field, of course?

Wojciech: That would be definitely about the future of AIF, how it is going to fit into the evolving integration landscape. Most importantly, what new features we may see coming to already take them into consideration in ongoing design processes.

6. Even if I wanted, (laughter) I am not able to feed your curiosity on that one, sorry ;). Moving on, do you remember a specific experience of where you wished that you and the customer had done something differently? If you were to do it over, what would you change?

Wojciech: No specific example comes to my mind. However, AIF is very flexible and you may say it’s a blessing and a curse as you get to make design decisions and have to deal with their consequences. It allows you to address challenges in various ways depending if your aim is for example best performance, scalability or ease of maintenance. Then when the time passes you may realize choosing a different approach might have been more beneficial after all.

7. A follow-up to the previous question: By way of comparison, do you remember something you’ve done or something you wish everyone was doing, and why?

Wojciech: It would be a pretty general advice applicable to all projects, planning in advance is the key here. Sometimes customers want to give AIF a try with a small set of interfaces and keep the rest of their interfaces out of the scope (or at least hold information on those other interfaces back). As I mentioned earlier, AIF is all about design decisions, so the more information is available at the planning level the better the design will be.

8. Wojciech, having written the book (together with Mateusz and Krzysztof) you must have come across a number of questions from the readers. Is there any that you are most tired of hearing on this subject, and what would you like to say about it so you never have to answer it again?

Wojciech: And that would be – (laughter) – “If we have AIF, do we still need SAP PI?”. The answer is not that simple and I would need to say “yes and no”. SAP PI is a different tool that serves different purposes. AIF’s goal is not to replace SAP PI but take over the tasks PI is not so good at. On the other hand SAP PI is better suited for other tasks like handling connectivity and traffic routing. So you don’t need both, but having both will give you best results.

9. You have brought the future to my attention and somehow I need to come back to it and ask you about the most critical changes that we must make to face the future effectively.

Wojciech: I think that it would be the mindset of the business support teams. If there is a chance that they do not recognize that AIF is a step in their direction we would need to make them aware of it, that AIF allows them to be more in control of business logic of the interfaces and rely less on technical teams in that regard.

10. To the three of you, What is the best resource for people who want to dive in deeper into the topic of SAP AIF?

Mateusz: I will take this one :), We can definitely recommend visiting our blog, as there are tons of materials regarding SAP AIF. Not to mention that there are two more books related to SAP AIF that we can recommend: Serializing Interfaces in SAP AIF and Mapping with BRFplus Decision Tables and SAP AIF. And it is not boasting off 🙂

11. Is there a question you have expected me to ask you, and I have not?

Mateusz: Yes, yes, yes (laughter) I counted on: What is your favourite part of the book?

12. Apologies 🙂 So, What is your favourite part of the book?

Mateusz: It’s definitely the part where Kris (Krzysztof) has explained how to set alerts based on some key fields. To be honest, I come back to this part every single time I have such a requirement from my customer.

Read also:

1. Test the components that are crucial to your business

2. Is every new project like returning to university?

The post Low hanging fruit a company can get from… appeared first on INT4.

In this article you will learn:

Reading time: 6 minutes

Introduction

During my projects, I often experience the situation when enterprise utilizes data exchange interfaces defined globally and they are expected to have the same logic for most of the situations. However, it can happen that the behavior of the interface needs to be slightly adjusted depending on some predefined parameters (like, for instance, company code).

Another example can be a situation where there is a need to slightly adjust a Standard SAP AIF Interfaces. Unfortunately, they can not  be changed directly on a customer system.

In those cases, Interface Variants come to help us!

How to create AIF Interface Variants?

Imagine, that you need to modify a standard SAP interface for incoming Business Partners: BUPA_IN. If the category of partner (PARTNERCATEGORY) is “Organization” then the fixed value “CORP” should be set into field PARTNERGROUP and a custom message should be added to the container.

This interface belongs to the namespace /AIF/, which was delivered by SAP That means that there is no possibility to change it directly and SAP AIF variants need to be used.

Step 1- Create a new variant

To create a new variant, go to transaction /AIF/CUST. Expand Interface Development->Interface Variants, then choose: Define Interface Variants:

As you can’t use /AIF/, provide your custom Namespace (we are going to use Namespace INT4):

Next, create a new entry and provide the variant’s name (e.g. ZBUPA_IN_PARTNERCAT ) and description:

Save your changes.

Step 2 – Variant Assigning Table

This type of table determines which variants should be assigned to an interface and which keyfields (parameters) should be used.  Please take note that one assigning table could be used for multiple interfaces.

To create a new variant assigning table, you need to copy the template table /AIF/VAR_AS_TMPL. Then, you need to add all expected parameters as the new key-fields.In our example the additional keyfield is the category of partner (PARTNERCATEGORY):

As a result, I have created a table  ZBUPAIN_VAR_TMPL with additional key-field PARTNERCATEGORY.

Next step is to fill this table with the expected data. I’m going to use the Table Maintenance View which I’ve created for this table. Here, create the new row and provide the information, including:

Now, when the configuration is done, save the row and assign this interface variant table to the variant.

Go back to the /AIF/CUST and choose Interface Development->Interface Variants then choose: Define Assigning Tables:

Next, choose the Namespace of the interface (here: /AIF/). You should see all interfaces belonging to this Namespace. Provide the name of the newly created Assigning Table and save:

Step 3 – Interface Key Fields

Go back to the Interface Development->Interface Variants then choose: Define Interface Key Fields:

Provide Namespace, Interface Name and version, then create a new row.

Use 10 as a Key Field Number, Choose PARTNERCATEGORY (you can use F4) as a Interface Variant Key Field. This value corresponds to the column name in the variant assigning table.

Next, provide Field Name, which should be the  field in the raw structure to where our parameter will  be mapped. You can use F4 here as well:

Save your changes. The customizing should now look like the following:

This setting ensures that, every time, if the value in the PARTNERCATEGORY matches values in the interface variant table ZBUPAIN_VAR_TMPL, then the configured Interface variant is selected to process the message.

Step 4 – Define Variant Mapping

In this step, we are going to map the newly created interface variant to the AIF interface.

Go to the Interface Development->Interface Variants then chose: Define Variant Mappings:

Then, select the Variant’s name (ZBUPA_IN_PARTNERCAT) and it’s Namespace (INT4).

In the next screen, press the button “New Entries” and provide information about the interface that should be assigned to the variant. The result should look like below:

Enter your namespace (here INT4) and create a new entry. Provide the Action’s name, Description and decide when the COMMIT WORK should be performed.

For our case, your customizing should look like the following:

Next, click on the Define Functions on the left and create a new entry. Use 10 as the function number and enter the new function module name, in our case ZFM_AIF_BUPA_CORPORATE . You can use the forward navigation to create the function module which is already having the correct structure but needs to be filled with the correct logic.

In our example, I created the custom Function Module ZCORPORATE_BUPA_SAVE copying and modifying the already pre-configured FM /AIF/TEST_AC_BUPA_SAVE. This module is used in a standard action BUPA_SAVE, which I’m  going to replace.

I made a small modification to replace the Success message that the BP was created to the Custom Warning with an information that the “Business Partner is an Organization”. I don’t have to put into the logic the check if the PARTNERCATEGORY = “Organization” because this validation is done on the Variant level:

When the Function Module is ready, it needs to be assigned to the Action.

Come back to the Configuration of the Action ZCORPORATE_BP, Choose “Define Functions”, then Add new row. Use 10 as a Function Number and ZCORPORATE_BUPA_SAVE as a FM name. Configuration should look like on the following screen:

Now, we have to assign an action to the interface variant.

You should come back to the place we were at the end of Step 4. (Interface Development->Interface Variants->Define Variant Mappings ) and choose our custom Variant.

Press “Assign Action” from tree on the left, and then “New Entries”:

Use 10 as a  number of action and as well provide Namespace, name and version of interface

Together with Namespace and the name of the custom variant:

Now, your action is assigned to the interface BUPA_IN, which ends the configuration of the AIF Variant.

Summary

Congratulations! Right now you can create AIF Variants!

Want to learn more about SAP AIF? Check other articles about SAP AIF on Int4 blog.

Read also:

1. Set up interface in SAP AIF Interface Monitor (/aif/ifmon)

2. Interface monitoring in business process context with SAP AIF and Process Observer

The post SAP AIF – How to create Interface Variants appeared first on INT4.