Dr. Julia Hambrock

Updated by KarstenBlankenstein

Solution OperationSupport

Readiness CheckA compilation of simple and advanced checks forthe Process Integration of Netweaver 2004 (XI 3.0)and Process Integration Netweaver 2004s (PI 7.0)

Version 4

05. Dezember 2007

Readiness Check

Page 2

Content:

Introduction........................................................................................................................3

1 Basic Checks ..................................................................................................................4

1.1 SLDCHECK ............................................................................................................................................4

1.2 Testing the HTTP services on the Integration Server ..........................................................................5

1.3 RFC Connections ..................................................................................................................................7

1.4 Testing the connection to the Integration Builder ...............................................................................8

1.5 Java Component Check ......................................................................................................................10

1.6 Netweaver Administrator ....................................................................................................................12

1.7 Testing the availability of the PI-JAVA applications..........................................................................14

1.8 Testing the connectivity between Integration Repository and SLD..................................................16

1.9 Testing the connectivity between Integration Directory and Integration Repository.......................16

1.10 Caches in PI .................................................................................................................................171.10.1 Cache Connectivity Test ............................................................................................................171.10.2 SXI_CACHE ..............................................................................................................................181.10.3 Adapter Engine Cache ...............................................................................................................191.10.4 Testing the CPA Cache..............................................................................................................20

1.11 Runtime Workbench (RWB).........................................................................................................22

1.12 Adapter Monitoring......................................................................................................................231.12.1 Adapter Monitoring via Communication Channel Monitoring .......................................................231.12.2 XI 3.0 <SPS 17 / PI 7.0 <SPS 8: Adapter Monitoring on the central and decentral Adapter

Framework........................................................................................................................................25

1.13 Backgroundjob Monitoring..........................................................................................................261.13.1 Background jobs running on the ABAP.......................................................................................261.13.2 Background jobs running on the J2EE engine ............................................................................26

2 Advanced Checks.........................................................................................................27

2.1 SLD Associations................................................................................................................................27

2.2 Testing cache notifications of the Integration Directory ...................................................................28

2.3 Small Scenario.....................................................................................................................................29

3 Additional tests for existing Scenarios ......................................................................30

3.1 Configuration Test...............................................................................................................................30

Readiness Check

Page 3

IntroductionTo simplify things we will use for both releases Exchange Infrastructure 3.0 and Process Integration 7.0 thename Process Integration (PI). From an architectural point both releases does not show significantdifferences (beside of HA specific facts).The following graphic shows the components that make up the SAP Process Integration. The SAP ProcessIntegration consists of the following functional components: Integration Builder, Integration Repository,Integration Directory, Integration Server, Integration Engine, Business Process Engine, Adapter Engine,Runtime Workbench (RWB) and System Landscape Directory (SLD)

Most of these components have to exchange information during runtime of the Process Integration. Thus, itis essential that each component can be accessed and that the communication between them is set upcorrectly. However, major changes of the PI infrastructure, especially when applying patches or whenchanging hostnames in the context of a High Availability setup, are potentially critical for the correctcollaboration of the PI components.

Therefore we recommend to carry out a set of simple checks that test the basic communication pathsbetween the PI components and strive to ensure a smooth runtime after a software patch or HA setup.These checks are divided into 2 groups: the first group is meant to be carried out by everyone and requireslittle to no knowledge about PI. The second group of checks is addressed to PI experts, e. g. developers orPI system administrators, and require a basic understanding of the Process Integration.

Readiness Check

Page 4

1 Basic ChecksThis group of checks can be carried out easily, with a small expenditure of time and does not requireextended PI know how.

1.1 SLDCHECK

The SLDCHECK is a useful transaction that tests several things:

Do the RFC connections SAPSLDAPI and LCRSAPRFC work?

Are the server access settings in transaction SLDAPICUST correct?

Is it possible to read data from the SLD and the Exchange Profile?

Does the Integration Server have a Business System defined?

ProcedureLog into the client of the Integration Server and call transaction SLDCHECK. This will open up a browserwindow which allows you to log into the SLD and thereby check if the SLD can be accessed by a dialog user.After verifying that you can logon to the SLD, go back to the R/3 window and check for the followingsuccessful checks:

In the section “Properties of RFC destination SAPSLDAPI” there should be the statement “RFC Pingsuccessful”

In the section “Calling function LCR_LIST_BUSINESS_SYSTEMS” there should be the statement“Function call terminated successfully” and you should be able to see a list of a few businesssystems

In the section “Calling function LCR_GET_OWN_BUSINESS_SYSTEM” there should be a statement“Function call terminated successfully” and you should see the business system of the integrationserver.

In the section “Calling function LCR_GET_BS_DETAILS” there should be a statement “Function callterminated successfully”. Check if the URL given in this section corresponds tohttp://<host>:80<sysnr>/sap/xi/engine?type=entry

In the section “Properties of RFC destination LCRSAPRFC” there should be the statement “RFCPing successful”

In the section “Calling function EXCHANGE_PROFILE_GET_PARAMETER” there should be thestatement “Function call terminated successfully”.

TroubleshootingIf you should experience errors while carrying out this check, use the online help for the SLD which providesa detailed problem analysis scenario. Use the link: Access To SLD From ABAP Fails.

Readiness Check

Page 5

1.2 Testing the HTTP services on the Integration Server

If an HTTP service is not running on the Integration Server, this can cause connection problems, which inturn can cause the notification of the cache on the Integration Server to fail or messages which not arrive inthe Integration Engine. This check controls the availability of important PI specific services for the cache andfor the pipeline.

Procedure:1. Start transaction SICF.

Choose default_host sap xi.All services should be active, particularly the services:- cache- cache_ssl- engine (for pipeline processing)- adapter_plain (for HTTP Adapter)

You can activate a service, by choosing the corresponding option in context menu.

2. Start transaction SICF.Choose default_host - sap bc ping (connection test)and then choose Test service in the context menu of the entry.

Readiness Check

Page 6

A browser should then open, prompting a logon. If the browser does not open, this indicatesa possible problem with the HTTP service of the SAP system and needs to be examined.

1.3 RFC Connections

Only two RFC connections are tested during the SLDCHECK, that is SAPSLDAPI and LCRSAPRFC. Theremaining RFC connections can be tested via transaction SM59. The AI_RUNTIME_JCOSERVERconnection is used to connect to the Java Mapping Runtime. The connection Integration_Directory_HMI isused to get data from the specific cache tables which contain the configuration data.

ProcedureLog into the client of the Integration Server and call transaction SM59. Test the following connections one ata time by double clicking on them and then pressing the button “Test connection”:

AI_RUNTIME_JCOSERVER (TCP/IP connection)

Integration_Directory_HMI

A successful test of the connections should look like this:

INTEGRATION_DIRECTORY_HMI (HTTP connection, use the XIISUSER with XI3.0 and thePIISUSER with PI 7.0 to authenticate). Is the Path Prefix set to “/dir/CacheRefresh” asrecommended since SP1 of XI 3.0?

Note that a HTTP 500 response is a successful test for this connection.

The connections SAPSLDAPI and LCRSAPRFC have already been checked with transactionSLDCHECK.

Readiness Check

Page 8

1.4 Testing the connection to the Integration Builder

Transaction SPROXY (a transaction usually used for the creation of proxies) provides 4 checks that can beused even if no proxies have been created in the PI landscape. The following aspects are tested:

The address of the Integration Builder

The HTTP connection of the Integration Server

The Integration Builder is running

The data of the Integration Builder is understood

ProcedureLog into the client of the Integration Server and call transaction SPROXY. Start the checks by going to GoTo-> Connection Test. This will give you a pop-up in which the tests can be started by clicking on the programnames highlighted in red.

The test SPROX_CHECK_IFR_ADDRESS should give you the status: OK: address maintained.

The screenshot for Release 2004s (PI) looks similar:

The test SPROX_CHECK_HTTP_COMMUNICATION should give you the information that thecommunication is working.

Readiness Check

Page 9

The test SPROX_CHECK_IFR_RESPONSE should give you a valid XML document.For higher SPS of XI 3.0 and also for release 2004s (PI) you should receive a confirmation that thecommunication is working:

The test SPROX_CHECK_IFR_CONNECTION should give you the information that thecommunication is working.

1.5 Java Component Check

The purpose of the check is to ensure that the java part is up and running from a technical perspective. If thischeck fails most of the subsequent checks will also fail.

Procedure:Open a Browser Window and type in the URL: http://<j2ee_host>:<j2ee_port>/index.html

If you can enter the page then this is the first hint that the dispatcher an the at least one server node is upand running and this specific application is started.

On this page you will find important application. Among others a link to the “System Information” page. Enterthe page by clicking on the link. A LogOn window appears. To LogOn you need j2ee_admin rights.

When you enter the page you will get an overview about the SAP Web AS Java and specific information toevery component.

Further below you find information to the dispatcher and server nodes. Green indicates that the component isup and running. Yellow and Grey should be investigated.

Readiness Check

Page 11

TroubleshootingFor error troubleshooting you find further information in SAP Note Analysis of errors within the startup ofJ2EE Engine.

Readiness Check

Page 12

1.6 Netweaver Administrator

The Netweaver Administrator becomes more and more important for the administration of an SAP doublestack system. Up to XI 3.0 SP 20 and PI 7.0 SP 13 a lot of functionalities can also be found in other tools butwith upcoming releases the Netweaver Administrator will become the only administration tool.

The purpose of this check is to verify if the Netweaver Administrator is ready to use.

Procedure:Open a Browser Window and type in the URL: http://<j2ee_host>:<j2ee_port>/index.html

Open the link SAP NetWeaver Administrator. A LogOn window appears. To LogOn you need j2ee_adminrights.

You can choose via the select box which system you want to administer/monitor.

When you access the Administration page System you should be able to see the status of the connectedsystem.

Readiness Check

Page 13

TroubleshootingIn case of problems check the Monitoring Set Up Guide for SAP NetWeaver in the SDN or underhttp://service.sap.com/operationsnw70 Monitoring and http://service.sap.com/nwa.

1.7 Testing the availability of the PI-JAVA applications

Procedure:

Log into the client of the Integration Server and call transaction SXMB_IFR. This will bring up a browserwindow with 4 links: Integration Directory, Integration Repository, Runtime Workbench and SystemLandscape Directory (SLD). The SLD has already been tested in the first check, so only the first threecomponents have to be tested at this point.

The following check cover the readiness and availability of the Integration Repository/ Integration Directoryand the Mapping Runtime.

Procedure:

Start a web browser and type in the following URL:

Integration Repository:http://<host name>:<port>/rep/hmidiag/ext?method=info

Integration Directory:http://<host name>:<port>/dir/hmidiag/ext?method=info

Mapping Runtime:http://<host name>:<port>/run/hmidiag/ext?method=info

(Host name and port can be determined from the SAP Process Integration start page.)

A logon dialog should be displayed. If it is not displayed, this indicates that the IntegrationRepository (or even J2EE) is not running and needs to be started.

Readiness Check

Page 16

1.8 Testing the connectivity between Integration Repository and SLD

Procedure:

Start the Integration Repository as described in the previous chapter. Go to ‘Tools’ -> ‘Transfer from SystemLandscape Directory’ -> ‘Import Software Component Versions’

This test is successful if you can see a list of Software Component Versions.

1.9 Testing the connectivity between Integration Directory andIntegration Repository

Procedure:

Start the Integration Directory as described in the previous chapter. Go to ‘Tools’ -> ‘Transfer IntegrationScenario from Integration Repository’. Then use the F4-Help for the Field ‘Name’.

This test is successful if you can see a list of Integration Scenarios from the Integration Repository.Cancel the Transfer once you have made sure that the list can be displayed properly.

Readiness Check

Page 17

1.10 Caches in PIIn SAP NetWeaver Process Integration information is often cached to speed up the input help of the tools orimprove performance of the runtime. Here different caches are used during design and during runtime.Important runtime caches are:

Integration Server ABAP (SXI Cache) Integration Server Java CPA Cache (Adapter Engine) SLD Cache (covered by SLD Check) Adapter Engine Cache

1.10.1 Cache Connectivity Test

The Runtime Workbench offers a Cache Connectivity Test with a comprehensive view on the most importantruntime caches. You use this function to check whether both steps for updating the runtime cache areworking correctly:

1) Notification of the components with cache data (consumers) using a cache refresh and

2) Retrieval and update of cache data by the consumer.

In this procedure, a change list with a test object is created in the Integration Repository and released, andthe Integration Directory is notified. The Integration Directory in turn notifies the relevant consumers, whothen retrieve the test data and update their runtime cache accordingly.

ProcedureLog into the client of the Integration Server and call transaction SXMB_IFR. This will bring up a browserwindow with a link to the RWB. Once logged in, go to the ‘Component Monitoring’ choose ‘All’ from thedropdown menu of the field “Component with Status” and hit the “Display” button. Navigate to the Test byusing the “Cache Connectivity Test” Button. To start the test hit the Button “Start Test”. Please note that youwill at first see yellow triangles that indicate that the test is still ongoing (the cache notifications and updatesneed some time) and that you will have to hit “Refresh Display”.

Check if all Cache Refreshes could be carried out, that is all components with cache data show agreen light.

In the above screenshot two Adapter Engines show a red light. These Adapter Engines are decentralAdapter Engines and were not online during the Cache Connectivity Test. Clicking on them enablestroubleshooting of the problem, in this case “Unable to establish http connection”:

Readiness Check

Page 18

Troubleshooting:

In case of any error check the following documents by clicking on the link.- “How to handle Caches with XPI Caches in SAP Netweaver 7.0”- “How to handle Caches with in SAP XI 3.0”

1.10.2 SXI_CACHE

Transaction SXI_CACHE lists most of the content of the Integration Repository and Integration Directory.This information is used by the Integration Server during runtime and it is thus critical that this information isalways up to date. A cache refresh is usually carried out automatically, but for testing purposes it can also bestarted manually. By carrying out a manual cache refresh several things can be tested, the most importantbeing:

Connection to the SLD and the Integration Builder

Correct entries in the SLD

ProcedureLog into the client of the Integration Server and call transaction SXI_CACHE. Start a manual cache refreshvia XI Runtime Cache Start Complete Cache Refresh (Shift + F6). This will trigger a background job thatcan be seen in transaction SM58 (its name is SAI_CACHE3_REFRESH_BACKGROUND). Once this isfinished check transaction SXI_CACHE for (be aware that a full cache refresh can take a while until befinished). Instead of a full cache refresh you can also trigger a delta cache refresh:

a green light for the PI Runtime Cache status, saying “cache contents are up-to date”

Readiness Check

Page 19

TroubleshootingIf you should observe a red light or a warning, navigate to the reported problems/errors (this is available forsupport packages 4).

For more information check regarding caches check the following documentation:- “How to handle Caches with XPI Caches in SAP Netweaver 7.0”- “How to handle Caches with in SAP XI 3.0”

In case the exception does not make sense to you, open an OSS ticket on component BC-XI.

1.10.3 Adapter Engine Cache

The Adapter Engine Cache contains the URL of the Adapter Engine. The information is used when amessage is sent from the Integration Engine to the Adpater Engine.

Procedure:Log into the client of the Integration Server and call transaction SXI_CACHE.

Navigate to: GoTo -> AE Cache

The test is successful if you find the URL of your Adapter Engine. Bear in mind that the cache isfilled when a first message has been processed and sent to the Adapter Engine.

TroubleshootingThe Adapter Engine URL is taken from the SLD where the Adapter Engine is registered. If you find the wrongURL listed then check the information in the SLD. For more information refer to the Troubleshooting Guide.

1.10.4 Testing the CPA Cache

The cache of the Adapter Engine is called CPA Cache. It contains information about all adapters that run onthe J2EE Engine. Thus, it is important that the refresh of this cache is working correctly.

Procedure:

Open a browser window and call the URL: http://<host>:5<sysnr>00/CPACache/refresh?mode=delta | full.Use the XIDIRUSER (PIDIRUSER) to authenticate yourself, it is the only user that is allowed to carry out aCPA Cache Refresh.

The test is successful if you get the message that the cache refresh has been carried out in xyzmilliseconds. Please note that any additional text. e. g. “The XML page cannot be displayed” or“invalid at the top level of the document”, points at an error.

You can also see the content/ history of cache refreshes in a browser window by calling the following URL:http://<host>:<port>/CPACache

Choose Display CPA Cache Content or View Cache Update History.

Readiness Check

Page 21

Troubleshooting:1) Note 741214 - Troublesh. during cache update of the J2EE CPACache service gives valuable hintsabout possible reasons for errors.2) In case of the error message “invalid at the top level of the document” the viewing of the source codeof the respective Explorer page gives detailed information about the error.

Readiness Check

Page 22

1.11 Runtime Workbench (RWB)

The Runtime Workbench is the central monitoring tool of the Process Integration. It offers self and statustests for most of the PI components: Integration Server, SLD; RWB, Adapter Framework, J2SE AdapterEngines, integrated Business Systems, Proxy Runtimes and Mapping Runtime.

Procedure:

Log into the client of the Integration Server and call transaction SXMB_IFR. This will bring up a browserwindow with a link to the RWB. Once logged in, go to the ‘Component Monitoring’ choose ‘All’ from thedropdown menu of the field “Component with Status” and hit the “Display” button.

In the list of components mark the radio button of the entries one by one and check if you get greenlights displayed at the bottom of the page

Click on every link in the Runtime Workbench and check if they open up without error messages.The links are: ‘Message Monitoring’, ‘End-to-End Monitoring’, ‘Performance Monitoring’, ‘IndexAdministration’, ‘Configuration’, ‘Alert Configuration’, ‘Alert Inbox’ and ‘Cache Monitoring’. For eachlink, carry out the specific action, e. g. try to display existing mapping programs in the CacheMonitoring. This test ensures that the connectivity between the RWB and ABAP as well as theconnectivity between the RWB and other JAVA applications works properly. In addition,authorizations of the XIRWBUSER (PIRWBUSER) are being checked.

Readiness Check

Page 23

1.12 Adapter Monitoring

With very few exceptions messages enter and leave the Process Integration via adapters. Some of them runon the Adapter Framework (typically JDBC, File, JMS, SOAP Adapter), some of them run on the integrationserver (IDoc Adapter, HTTP plain adapter). You may also use the J2SE standalone adapter engine ordecentral adapter engines.

Starting with XI 3.0 SPS 17 / PI 7.0 SPS 08 a new Communication Channel monitor was introduced. Unlikethe existing adapter monitor, the communication channel monitor also provides current runtime informationabout the communication channels of individual adapters, as long as they are registered for communicationchannel monitoring.

To monitor adapters that do not provide runtime information to communication channel monitoring, continueto use the adapter monitor. For all standard adapters the Communication Channel monitor is the tool to beused and no information will be displayed in the Adapter Monitor.

1.12.1 Adapter Monitoring via Communication Channel Monitoring

Procedure:

Logon to the Runtime Workbench start page (e. g. by running transaction SXMB_IFR and using thelink in the browser window) and choose component monitoring. A first indicator about the status ofthe communication channels is already given by the result of the self-test in the ComponentMonitoring of the RWB for a selected Adapter Engine. If you see a read light in the CommunicationChannel (CC) monitoring this already indicates that there are CC in error. When clicking on theDetails link you will see an overview about the status of the Communication Channels as shown inthe screenshot below.

Check that the Communication Channels that are in use, display a green light. If you observe a redlight, have a look at the Error messages displayed on the bottom of the page and inform therespective Application People/ Administrator/ Developer..

Readiness Check

Page 24

Readiness Check

Page 25

1.12.2 XI 3.0 <SPS 17 / PI 7.0 <SPS 8: Adapter Monitoring on the central anddecentral Adapter FrameworkThe adapter monitoring has to be used, if adapters do not provide runtime information to communicationchannel monitoring.

ProcedureLog on to the RWB start page and navigate to “Component Monitoring”. Choose display of all componentsand select the appropriate Adapter Engine. Click on the button “Adapter Monitoring”.

Check that the Adapters that are in use, display a green light. If you observe a red light, have a lookat the Error messages and inform the respective Application People. Note that the content of thisAdapter Monitor varies with the support package of your PI.

1.13 Backgroundjob MonitoringThe housekeeping jobs for PI ensure a smoothly running Process Integration. They do not only carry out thearchiving and deletion, but also care for performance data and retry mechanisms. Even you should have notscheduled any jobs up to now there are some standard jobs which are scheduled during installation.

1.13.1 Background jobs running on the ABAP

When you have set up a PI System you will not find PI specific jobs running. On the ABAP part thebackground jobs need to be scheduled manually. You can find a good overview which jobs might need toscheduled under the note: Note 884865 - PI/XI Admin Check -> Job Monitoring of Housekeeping Jobs.

1.13.2 Background jobs running on the J2EE engineIn the J2EE engine a number of background jobs are scheduled during the installation process. Thez shouldbe checked if they run smoothly.

ProcedureLog in to the RWB and call your central or decentral Adapter Engine in the Component Monitoring. Choosethe button “Background Processing”. A new window opens displaying the background processes beingexecuted in your Java environment.

Check if a default deletion job is scheduled and in status green

Check if a default Recover Job is scheduled and in status green

Additional jobs to be monitored here could be the automatic message restart job or the archiving job ifscheduled.

Readiness Check

Page 27

2 Advanced ChecksThe following tests take up more time and require a certain degree of insight into the architecture of theProcess Integration, especially for the last check of this chapter.

2.1 SLD Associations

For several application processes it is required that the PI components all belong to the same ‘domain’. Thisdomain and the associations of this domain are set during start-up of the system. However, when changingthe hostname of the Integration Server the associations may become inconsistent and it is necessary torecheck / recreate them.

Procedure:

Log into the client of the Integration Server and call transaction SXMB_IFR. This will bring up a browserwindow with a link to the SLD. Once logged in go to the link “Technical Infrastructure” and choose “ExchangeInfrastructure” from the drop down menu.

Check if the Integration Server has a Domain assigned (in the screenshot below the Domain of theXI 3.0 Integration Server YIS is pwdf2031).

Check if for the above Domain there are all components registered as well: Adapter Engine,Integration Directory, Integration Repository and RWB.

Check if there are other Domains that are no longer used.

Troubleshooting:

See note Note 764176 - Error in XI due to inconsistent SLD contents if you find any inconsistencies.

Readiness Check

Page 28

2.2 Testing cache notifications of the Integration Directory

For the development of scenarios it has to be ensured that the newly created information about objects(interface determinations, mappings etc.) is transmitted to the two components that need the information atruntime: the Adapter Framework and the Integration Server. The Integration Directory provides you with aNotification Service that is available via the menu entry “Environment” at the top of the user interface. Thisnotification shows green/red status lights of cache notifications to the Integration Server as well as to theAdapter Framework.

Since the creation or the change of an existing object is required to carry out this test, it is NOTrecommended for productive systems.

Procedure:

Log into the Integration Directory and open an existing object. You may also create a new one if you prefer.If you choose to open an existing object, go into the edit mode afterwards and make a small change (likeremoving and subsequently adding a character in the description of the object). This small change is neededto be able to save and activate the object again. After saving and activating the cache notifications arestarted automatically.

Check if both notifications are executed successfully, that is they show a green light.

Readiness Check

Page 29

2.3 Small Scenario

The ultimate test to ensure that the PI landscape is working correctly is to create a little scenario and carry itout. In this way all development tools as well as the runtime is tested. This does not require as much time asthe development of scenarios for your business processes since a very easy set-up can be chosen and sincethis procedure could be documented within your company.

A suggestion would be to create a File Adapter for the Integration Server. This File Adapter would poll a *.txtfile from a test folder, convert it into an XML and send it to the PI Integration Server. Create a simplemapping, for example rename the XML tags of your test file, that is then carried out in the Integration Server.The endpoint can again be a simple File Adapter that would store the mapped file into an archive folder.

If you need a more detailed description about how to set up a scenario, we recommend to implement thedemo scenario for which SAP provides a detailed documentation as well as delivers the relevant objects inthe Integration Repository (Software Component Version SAP Basis 640). The demo scenario can be foundat help.sap.com under following link: Demo Examples (NW 2004) or Demo Examples (NW 2004s)

Readiness Check

Page 30

3 Additional tests for existing Scenarios

3.1 Configuration Test

For PI there is the opportunity to test the configuration of your scenarios. The test is called “configurationtest” and is part of the Integration Builder Directory. During the configuration test, the individual pipelineservices of the Integration Server are called, and the change to the message in each case is simulated in theindividual processing steps.

The advantage of this test is the detailed test report after having executed the test. If there are errors, it ispossible to navigate to the relevant configuration objects and to see the errors on the “Error Log” tab page.Detailed information can be found in the online documentation.

Procedure:

Log on to the Integration Builder Directory and go to Tools -> Test Configuration. Define the inputparameters like header data and a payload if required. Then start the test for the either the whole pipeline(”Run”) or for single pipeline steps (“Step Over”).

Check if all pipeline steps are executed successfully, that is they show a green light for a single stepand that the status is the black/white flag for a successful processing of the whole pipeline.